{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-otimizacao-do-debito-da-rede-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting: otimizar o desempenho do servidor e o d\u00e9bito da rede"},"content":{"rendered":"<p>Eu mostro como <strong>softirq cpu<\/strong> juntamente com a NAPI, a distribui\u00e7\u00e3o de IRQ e o design de filas limita ou liberta o d\u00e9bito da rede no alojamento. Com pontos de medi\u00e7\u00e3o claros, afina\u00e7\u00e3o direcionada e afinidades limpas, reduzo <strong>Lat\u00eancias<\/strong> e aumentar consistentemente a taxa de transfer\u00eancia de pps em servidores produtivos.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Estas ideias nucleares transportam os pacotes de rede de forma eficiente atrav\u00e9s da CPU, do kernel e da placa de rede - e mant\u00eam os tempos de resposta a um n\u00edvel m\u00ednimo. <strong>constante<\/strong> baixo.<\/p>\n<ul>\n  <li><strong>Or\u00e7amento NAPI<\/strong> ajuste fino: Mais pacotes por sondagem reduzem as despesas gerais e suavizam o <strong>Carga da CPU<\/strong>.<\/li>\n  <li><strong>Equil\u00edbrio de IRQ<\/strong> e afinidade: evitar hotspots, aumentar os acessos \u00e0 cache, <strong>Picos de lat\u00eancia<\/strong> pressionar.<\/li>\n  <li><strong>Fila m\u00faltipla<\/strong>, RSS\/RPS\/XPS: paralelizar fluxos, manter o alinhamento NUMA, <strong>pps<\/strong> aumentar.<\/li>\n  <li><strong>Descargas<\/strong> utilizar conscientemente: GRO\/LRO, TSO, avaliar a coalesc\u00eancia, <strong>Jitter<\/strong> em vista.<\/li>\n  <li><strong>Isolamento<\/strong> e Busy Polling: Tempos de resposta previs\u00edveis em sistemas dedicados <strong>N\u00facleos<\/strong>.<\/li>\n<\/ul>\n\n<h2>No\u00e7\u00f5es b\u00e1sicas: O que acontece no kernel durante o tr\u00e1fego de rede<\/h2>\n<p>Um pacote chega primeiro a uma interrup\u00e7\u00e3o de hardware, ap\u00f3s o que o kernel assume o trabalho em <strong>SoftIRQs<\/strong> e loops de sondagem NAPI. Eu me certifico de que a fase r\u00e1pida do HardIRQ permane\u00e7a realmente curta e que a l\u00f3gica real se mova para o contexto correto para que o <strong>tempo de CPU<\/strong> n\u00e3o se esgota. As threads ksoftirqd s\u00f3 entram em cena se o processamento direto n\u00e3o for poss\u00edvel, o que leva rapidamente a filas de espera sob carga cont\u00ednua. \u00c9 exatamente aqui que surge o tempo de espera, que se reflecte no aumento do TTFB e na flutua\u00e7\u00e3o do d\u00e9bito. Se voc\u00ea quiser se aprofundar, pode encontrar conhecimento pr\u00e1tico sobre o processamento de IRQ neste artigo sobre <a href=\"https:\/\/webhosting.de\/pt\/tratamento-de-interrupcoes-no-servidor-otimizacao-do-desempenho-do-cpu-7342\/\">Tratamento de interrup\u00e7\u00f5es e desempenho da CPU<\/a>, que utilizo para a categoriza\u00e7\u00e3o.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQs e ksoftirqd: controlar a lat\u00eancia em vez de a gerir<\/h2>\n<p>A NAPI reduz as tempestades de interrup\u00e7\u00f5es, recolhendo v\u00e1rios pacotes por execu\u00e7\u00e3o dentro de um or\u00e7amento definido e minimizando assim o tempo de interrup\u00e7\u00e3o. <strong>Despesas gerais<\/strong> diminui. Se o or\u00e7amento n\u00e3o for suficiente, as encomendas amontoam-se, a procura aquece e o <strong>Lat\u00eancia<\/strong> aumenta de forma mensur\u00e1vel. Em tais situa\u00e7\u00f5es, eu verifico sistematicamente \/proc\/softirqs e \/proc\/net\/softnet_stat para visualizar quedas, time_squeeze ou filas transbordando. Depois, aumento gradualmente o net.core.netdev_budget ou net.core.netdev_budget_usecs e monitorizo a carga da CPU, a distribui\u00e7\u00e3o p95\/p99 e as perdas de pacotes em paralelo. O truque \u00e9 conseguir trabalho suficiente por sondagem sem atrapalhar a execu\u00e7\u00e3o interativa das threads do userland.<\/p>\n\n<h2>Equil\u00edbrio e afinidade de IRQ: evitar pontos de acesso, aumentar os acessos \u00e0 cache<\/h2>\n<p>Um \u00fanico n\u00facleo com todos os IRQs da NIC torna-se um gargalo porque tem de servir interrup\u00e7\u00f5es, IRQs suaves, bem como threads de aplica\u00e7\u00f5es; assim, distribuo <strong>IRQs<\/strong> direcionado. O servi\u00e7o irqbalance ajuda, mas para taxas de pps elevadas, mapeio explicitamente as filas RX\/TX atrav\u00e9s de afinidade para <strong>n\u00facleos<\/strong>. Nos sistemas NUMA, as filas de espera s\u00e3o ligadas a n\u00facleos do mesmo n\u00f3 para evitar acessos remotos \u00e0 mem\u00f3ria. Os threads de aplica\u00e7\u00e3o s\u00e3o executados em n\u00facleos vizinhos mas separados, o que melhora a localidade da cache e a capacidade de programa\u00e7\u00e3o. Este guia de distribui\u00e7\u00e3o estrat\u00e9gica fornece uma boa vis\u00e3o geral do <a href=\"https:\/\/webhosting.de\/pt\/servidor-irq-balancing-otimizacao-do-desempenho-da-rede-centro-de-dados\/\">Equil\u00edbrio de IRQ no centro de dados<\/a>, que utilizo como refer\u00eancia para afina\u00e7\u00f5es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Filas m\u00faltiplas, RSS\/RPS\/XPS: utiliza\u00e7\u00e3o correta da paraleliza\u00e7\u00e3o<\/h2>\n<p>As placas de rede modernas v\u00eam com v\u00e1rias filas RX\/TX, que posso controlar atrav\u00e9s de <strong>RSS<\/strong> para os fluxos e assim conseguir um paralelismo real. Se a placa oferecer muito poucas filas, uso o RPS\/XPS para fazer ajustes no software, a fim de distribuir os pacotes de forma sensata entre os fluxos. <strong>n\u00facleos<\/strong> para enviar. A distribui\u00e7\u00e3o limpa de hash \u00e9 importante para que um fluxo permane\u00e7a sempre na mesma CPU e n\u00e3o ocorram distor\u00e7\u00f5es caras no cache. Ao mesmo tempo, mantenho os caminhos TX e RX pr\u00f3ximos para evitar conten\u00e7\u00e3o de bloqueio e acessos desnecess\u00e1rios entre n\u00f3s. Isso aumenta a taxa de transfer\u00eancia de pps sem que um \u00fanico n\u00facleo puxe os freios.<\/p>\n\n<h2>Afinidade com a CPU diretamente no espa\u00e7o do utilizador: pensamento de ponta a ponta<\/h2>\n<p>Planeio o caminho dos dados desde a NIC-IRQ atrav\u00e9s das filas NAPI at\u00e9 \u00e0s threads de trabalho da aplica\u00e7\u00e3o, de modo a que os pacotes cheguem ao seu destino sem hooks desnecess\u00e1rios e a <strong>Tempo de resposta<\/strong> permanece constante. Para o conseguir, separo consistentemente os n\u00facleos para interrup\u00e7\u00f5es\/softIRQs dos n\u00facleos de aplica\u00e7\u00f5es e crio n\u00facleos <strong>Afinidade<\/strong>-regras. Servidores Web, proxies reversos e bancos de dados recebem conjuntos fixos de CPU que est\u00e3o pr\u00f3ximos aos n\u00facleos IRQ para manter os caminhos curtos. Al\u00e9m disso, eu defini o regulador de CPU para desempenho para que as mudan\u00e7as de rel\u00f3gio n\u00e3o empurrem o jitter para o p99. Esta atribui\u00e7\u00e3o consistente torna o comportamento previs\u00edvel e ajuda a diagnosticar gargalos de forma limpa.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Descargas, GRO\/LRO, firewall e eBPF: Poupe carga sem andar \u00e0s cegas<\/h2>\n<p>Guardar a descarga da soma de controlo, TSO e coalesc\u00eancia <strong>tempo de CPU<\/strong>, No entanto, podem alterar o tamanho dos pacotes, o comportamento das rajadas e o jitter, raz\u00e3o pela qual me\u00e7o especificamente os efeitos. O GRO\/LRO agrupa os quadros e reduz a carga na pilha, mas para os requisitos em tempo real, decido numa base situacional sobre <strong>Desativa\u00e7\u00e3o<\/strong> ou de uso limitado. As tabelas Conntrack e as cadeias nftables\/iptables profundas custam rel\u00f3gios, por isso arrumo as regras sup\u00e9rfluas e simplifico os caminhos. Se necess\u00e1rio, recorro ao eBPF (XDP, tc-BPF) para tomar decis\u00f5es antecipadas na placa de rede e evitar caminhos dispendiosos. Um bom ponto de partida para a pr\u00e1tica do ajuste fino \u00e9 esta vis\u00e3o geral de <a href=\"https:\/\/webhosting.de\/pt\/coalescencia-de-interrupcoes-otimizacao-da-rede-serverflux\/\">Coalesc\u00eancia de interrup\u00e7\u00f5es<\/a>, que tenho em conta para or\u00e7amentos de lat\u00eancia sens\u00edveis.<\/p>\n\n<h2>Sondagem de ocupa\u00e7\u00e3o e isolamento da CPU: Bloqueio dos tempos de resposta<\/h2>\n<p>Para alvos de lat\u00eancia dif\u00edcil, eu uso polling ocupado para que os sockets do espa\u00e7o do utilizador apanhem os pacotes ainda mais cedo e <strong>Tempos de espera<\/strong> encurtar. Isto aumenta a carga, mas proporciona-me distribui\u00e7\u00f5es muito estreitas de p99 para API ou cargas de trabalho de negocia\u00e7\u00e3o em servidores dedicados <strong>N\u00facleos<\/strong>. Al\u00e9m disso, isolo os n\u00facleos com isolcpus=, nohz_full= e rcu_nocbs= para que os temporizadores, a RCU e os servi\u00e7os do sistema sejam executados apenas nas CPUs de manuten\u00e7\u00e3o. Esta separa\u00e7\u00e3o evita interfer\u00eancias nos n\u00facleos de lat\u00eancia e torna o comportamento reproduz\u00edvel. O resultado \u00e9 um roteiro claro: n\u00facleos dedicados, recolha precoce de pacotes, or\u00e7amentos definidos.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas: do sintoma \u00e0 causa<\/h2>\n<p>Come\u00e7o com pps, taxa de transfer\u00eancia e carga do n\u00facleo, depois verifico as quedas e a atividade do <strong>ksoftirqd<\/strong>-threads ao longo do tempo para reconhecer padr\u00f5es de forma fi\u00e1vel. Ferramentas como sar, htop, ss, nload e ethtool mostram-me quando e onde ocorre o congestionamento e se o <strong>Tacos<\/strong> atingem os seus limites. As distribui\u00e7\u00f5es s\u00e3o importantes em vez dos valores m\u00e9dios para que os picos noturnos, as janelas do cron ou as campanhas n\u00e3o se percam. Eu correlaciono os picos de TTFB com a distribui\u00e7\u00e3o de IRQ, o or\u00e7amento da NAPI e as configura\u00e7\u00f5es de descarregamento para fazer ajustes direcionados. Uma afinidade de IRQ ajustada ou um novo or\u00e7amento NAPI adaptado \u00e9 muitas vezes suficiente para reduzir visivelmente os tempos limite.<\/p>\n\n<h2>Par\u00e2metros de afina\u00e7\u00e3o num relance<\/h2>\n<p>A vis\u00e3o geral que se segue ajuda-me a utilizar as altera\u00e7\u00f5es de forma sensata e a atribuir claramente os efeitos antes de efetuar altera\u00e7\u00f5es permanentes. <strong>lan\u00e7amentos<\/strong> plano. Testo cada ajuste iterativamente, me\u00e7o as distribui\u00e7\u00f5es de lat\u00eancia e observo os efeitos colaterais em <strong>CPU<\/strong> e mem\u00f3ria. S\u00f3 altero um ponto por janela de teste para que a causa e o efeito permane\u00e7am claros. Em seguida, documento os resultados e defino valores-limite para os alertas. Desta forma, obtenho melhorias reproduz\u00edveis sem correr o risco de surpresas no tr\u00e1fego produtivo.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metro\/carater\u00edstica<\/th>\n      <th>Efeito no percurso dos dados<\/th>\n      <th>Quando angariar\/ativar<\/th>\n      <th>Riscos\/efeitos secund\u00e1rios<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Mais pacotes por sondagem NAPI<\/td>\n      <td>Para gotas em softnet_stat<\/td>\n      <td>As sondagens mais longas substituem os t\u00f3picos dos utilizadores<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Limitar a janela de tempo por sondagem<\/td>\n      <td>Para o jitter devido a grandes rajadas<\/td>\n      <td>Demasiado pequeno: mais altera\u00e7\u00f5es de contexto<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>Distribuir fluxos pelos n\u00facleos<\/td>\n      <td>Para hotspots num n\u00facleo<\/td>\n      <td>Hashes incorrectos: distor\u00e7\u00f5es da cache<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Afinidade IRQ<\/strong><\/td>\n      <td>Associar IRQs perto do n\u00facleo<\/td>\n      <td>Com NUMA-Missmatch<\/td>\n      <td>A m\u00e1 afeta\u00e7\u00e3o de recursos cria novos focos de tens\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Reduz o n\u00famero de pacotes<\/td>\n      <td>Para estrangulamento da CPU<\/td>\n      <td>Jitter, rajadas maiores<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Sondagem ocupada<\/strong><\/td>\n      <td>Recolha antecipada de encomendas<\/td>\n      <td>Para alvos dif\u00edceis do p99<\/td>\n      <td>Maior consumo de CPU<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>An\u00e9is RX\/TX e profundidade de cue: dimensionar corretamente os buffers<\/h2>\n<p>Mesmo com IRQs corretamente distribu\u00eddos e or\u00e7amentos adequados, os an\u00e9is de placa de rede demasiado pequenos ou demasiado grandes podem reduzir o desempenho. Por isso, verifico os tamanhos dos an\u00e9is RX\/TX da placa e adapto-os aos objectivos de car\u00e1cter burst e lat\u00eancia. Os an\u00e9is demasiado pequenos provocam quedas na placa de rede durante os picos de tr\u00e1fego, vis\u00edveis como rx_missed_errors ou fifo_errors nas estat\u00edsticas do controlador. Os an\u00e9is demasiado grandes disfar\u00e7am o congestionamento, aumentam a lat\u00eancia e criam longos trailing edges em p95\/p99. Estou \u00e0 procura do meio termo: buffer suficiente para absorver rajadas curtas, mas n\u00e3o tanto que os pacotes \u201cenvelhe\u00e7am\u201d nas filas.<\/p>\n<p>Para al\u00e9m disso, analiso o lado do anfitri\u00e3o <strong>tx_queue_len<\/strong> e o Qdisc utilizado. Com sch_fq ou fq_codel posso suavizar o comportamento de burst e distribuir grandes pacotes TSO atrav\u00e9s de pacing. Isso reduz microbursts na porta do switch e torna a curva de lat\u00eancia mais suave - importante para cargas de trabalho mistas nas quais pequenos RPCs s\u00e3o executados juntamente com grandes uploads. Eu monitorizo as estat\u00edsticas ethtool e correlaciono-as com softnet_stat para reconhecer se o congestionamento est\u00e1 a ocorrer no anel NIC, no backlog netdev ou no Qdisc.<\/p>\n\n<h2>MTU, jumbo frames e segmenta\u00e7\u00e3o<\/h2>\n<p>O <strong>MTU<\/strong> \u00e9 uma alavanca cl\u00e1ssica que \u00e9 frequentemente subestimada. Os Jumbo frames reduzem o n\u00famero de pacotes por Gbit\/s e reduzem a carga na CPU - mas apenas se o caminho for verdadeiramente capaz de jumbo de ponta a ponta. Por isso, valido sistematicamente as esta\u00e7\u00f5es remotas, os comutadores e os t\u00faneis. Assim que houver uma fragmenta\u00e7\u00e3o de volta a 1500 em algum lugar, h\u00e1 o risco de problemas de MTU no caminho, retransmiss\u00f5es e <strong>Jitter<\/strong>. Em centros de dados com comunica\u00e7\u00e3o dominante Este\/Oeste, vale a pena uma estrat\u00e9gia homog\u00e9nea de 9k, enquanto 1500 \u00e9 frequentemente a escolha mais est\u00e1vel para cargas de trabalho viradas para a Internet.<\/p>\n<p>Avalio sempre o MTU em conjunto com <strong>TSO\/GSO\/GRO<\/strong>Um agrupamento demasiado agressivo pode levar a grandes explos\u00f5es no TX que enchem os buffers a montante e geram picos de lat\u00eancia. O objetivo \u00e9 um caminho consistente: segmenta\u00e7\u00e3o sensata no transmissor, mecanismos de estimula\u00e7\u00e3o suficientes e GRO que poupam trabalho no lado do recetor sem frustrar os requisitos de tempo real.<\/p>\n\n<h2>UDP, QUIC e cargas de trabalho de fluxo cont\u00ednuo: considere as especificidades<\/h2>\n<p>Nem todo o tr\u00e1fego \u00e9 TCP. <strong>UDP<\/strong>perfis pesados (DNS, VoIP, QUIC, telemetria) comportam-se de forma diferente em RSS\/RPS e GRO. As pilhas modernas suportam UDP-GRO\/GSO, o que pode reduzir a carga na CPU - utilizo-o seletivamente e me\u00e7o se os riscos de reordena\u00e7\u00e3o ou o aumento do jitter aumentam. Para cargas QUIC\/HTTP3, a distribui\u00e7\u00e3o limpa de fluxos \u00e9 crucial: o RPS pode ajudar se a placa de rede oferecer poucas filas RSS, mas n\u00e3o deve \u201cjogar fora\u201d nenhum fluxo de cache quente. No lado do TX, defini <strong>XPS<\/strong> para agrupar caminhos de transmiss\u00e3o e reduzir a conten\u00e7\u00e3o de bloqueios. Na pr\u00e1tica, uma aloca\u00e7\u00e3o silenciosa e com afinidade de n\u00facleo compensa, especialmente com muitos fluxos UDP de tamanho m\u00e9dio em que cada acerto de cache conta.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o e contentores: integra\u00e7\u00e3o simples de anfitri\u00e3o, convidado e vhost<\/h2>\n<p>Em ambientes virtualizados, o trabalho alterna entre host, threads vhost e IRQs guest. Certifico-me de que <strong>vhost-net<\/strong>-Os threads recebem seus pr\u00f3prios n\u00facleos e n\u00e3o colidem com os trabalhadores de aplicativos. Suas afinidades devem corresponder \u00e0s filas RX\/TX f\u00edsicas, caso contr\u00e1rio, haver\u00e1 migra\u00e7\u00e3o desnecess\u00e1ria entre CPUs. No convidado, eu verifico as filas da virtio-net, ativo a fila m\u00faltipla e configuro o RSS\/RPS an\u00e1logo ao bare metal. Onde a lat\u00eancia e os pps est\u00e3o em primeiro plano <strong>SR-IOV<\/strong> reduzir ainda mais as despesas gerais - o pr\u00e9-requisito \u00e9 uma topologia NUMA consistente: VF, vCPU e mem\u00f3ria pertencem ao mesmo n\u00f3.<\/p>\n<p>Na pilha de contentores, as redes sobrepostas, as cadeias NAT profundas e as topologias CNI complexas causam saltos adicionais. Para servi\u00e7os cr\u00edticos de lat\u00eancia, prefiro hostNetwork ou redes enxutas (macvlan\/ipvlan), equalizo os caminhos NAT e mantenho <strong>Conntrack<\/strong> t\u00e3o pequeno quanto poss\u00edvel. \u00c9 importante uma estrat\u00e9gia de CPU consistente: os n\u00facleos IRQ e NAPI do anfitri\u00e3o devem estar localizados na vizinhan\u00e7a dos n\u00facleos em que os trabalhadores vhost\/contentor est\u00e3o a funcionar - esta \u00e9 a \u00fanica forma de manter o caminho dos dados curto e previs\u00edvel.<\/p>\n\n<h2>Agendamento, C-States e IRQ-Threading<\/h2>\n<p>Porque a lat\u00eancia n\u00e3o \u00e9 apenas o tempo de computa\u00e7\u00e3o, mas tamb\u00e9m <strong>Hora de despertar<\/strong> Eu minimizo os estados C profundos nos n\u00facleos de lat\u00eancia. Uma poupan\u00e7a de energia agressiva pode custar milissegundos antes de um SoftIRQ ser efetivamente executado. Por isso, confio nos reguladores de desempenho, limito os C-states profundos e mantenho o turbo consistente para tornar previs\u00edveis os saltos de frequ\u00eancia. Igualmente importante \u00e9 <strong>Encadeamento de IRQ<\/strong>Onde os drivers o permitem, eu transfiro o trabalho para threads IRQ e priorizo para que o RX inicie antes do trabalho downstream sem deslocar completamente o userland. A intera\u00e7\u00e3o das pol\u00edticas de agendamento, afinidades e or\u00e7amentos \u00e9 complicada; eu testo passo a passo, registo p99 e tenho cuidado com a interfer\u00eancia com o ksoftirqd, que de outra forma se torna um estrangulamento secreto.<\/p>\n\n<h2>Observa\u00e7\u00e3o em profundidade: pontos de rastreio, contadores, histos<\/h2>\n<p>Se as m\u00e9tricas permanecerem vagas, vou a um n\u00edvel mais profundo: utilizo tracepoints do kernel em torno de <strong>netif_receive_skb<\/strong>, <strong>napi_poll<\/strong> e <strong>fila_dev_rede<\/strong>, para ver as dura\u00e7\u00f5es das sondagens, volumes de pacotes e tempos de espera como histogramas. Estas distribui\u00e7\u00f5es mostram se 1 % das sondagens est\u00e3o a demorar demasiado tempo ou se as filas individuais est\u00e3o a esgotar-se. Al\u00e9m disso, o ethtool-<strong>rx\/tx<\/strong>-counters, TCP retransmits, busy poll hits e softnet_stat indicam claramente onde os pacotes est\u00e3o a ser perdidos. Utilizo a an\u00e1lise de queda para reconhecer se a placa de rede est\u00e1 a cair (anel cheio), se o backlog do netdev est\u00e1 a colapsar (time_squeeze) ou se o Qdisc\/firewall est\u00e1 a abrandar. S\u00f3 quando estas pe\u00e7as do puzzle se encaixam \u00e9 que ajusto os an\u00e9is, os or\u00e7amentos ou as descargas.<\/p>\n\n<h2>Simplificar os caminhos de seguran\u00e7a e filtragem<\/h2>\n<p>ACLs complexas, cadeias nftables\/iptables profundas e tabelas conntrack amplas adicionam lat\u00eancia constante por pacote. Eu consolido regras, trabalho com conjuntos\/mapas e movo drops gen\u00e9ricos o mais adiante poss\u00edvel no caminho - idealmente o mais cedo poss\u00edvel na NIC (XDP\/clsact) se a lat\u00eancia for cr\u00edtica. Fluxos sem estado, telemetria ou portas \u201cseguras\u201d conhecidas podem ser usados de forma direcionada. <strong>sem rastreio<\/strong> para eliminar a necessidade de pesquisas dispendiosas. Ao mesmo tempo, mantenho as tabelas de estado actualizadas, ajusto os tamanhos de hash aos picos de carga e arrumo agressivamente as entradas \u00f3rf\u00e3s. O objetivo \u00e9 um caminho de pol\u00edtica limpo e rastre\u00e1vel que n\u00e3o seja percet\u00edvel no perfil como uma carga permanente.<\/p>\n\n<h2>Anti-padr\u00f5es t\u00edpicos e como os evito<\/h2>\n<ul>\n  <li><strong>Todos os IRQs num n\u00facleo:<\/strong> leva ao congestionamento e ao aquecimento. Ant\u00eddoto: afinidades direcionadas por pista, coerentes com NUMA.<\/li>\n  <li><strong>Maximiza\u00e7\u00e3o cega de an\u00e9is\/or\u00e7amentos:<\/strong> oculta o congestionamento, aumenta as caudas de lat\u00eancia. Ant\u00eddoto: aumentar gradualmente, medir as distribui\u00e7\u00f5es.<\/li>\n  <li><strong>Configura\u00e7\u00e3o incorrecta do hashing de fluxo:<\/strong> Os fluxos saltam entre os n\u00facleos, as caches desaparecem. Ant\u00eddoto: chaves RSS est\u00e1veis, RPS\/XPS apenas com um objetivo claro.<\/li>\n  <li><strong>Threads de aplica\u00e7\u00f5es nos mesmos n\u00facleos que os SoftIRQs:<\/strong> Interfer\u00eancias e instabilidade. Ant\u00eddoto: separa\u00e7\u00e3o r\u00edgida, atribui\u00e7\u00e3o por vizinhan\u00e7a.<\/li>\n  <li><strong>Sobreposi\u00e7\u00f5es\/NAT sem or\u00e7amento:<\/strong> adicionados a cada salto. Solu\u00e7\u00e3o: simplificar os caminhos, hospedar redes para cargas de trabalho com lat\u00eancia.<\/li>\n  <li><strong>Poupan\u00e7a de energia em n\u00facleos de lat\u00eancia:<\/strong> Os estados C profundos abrandam a rea\u00e7\u00e3o. Ant\u00eddoto: regulador de desempenho, limita\u00e7\u00e3o do estado C.<\/li>\n  <li><strong>Descargas sem medi\u00e7\u00e3o:<\/strong> O TSO\/GRO pode exacerbar as rajadas e o jitter. Solu\u00e7\u00e3o: Ativar carga de trabalho espec\u00edfica, monitorizar p99.<\/li>\n<\/ul>\n\n<h2>Acolhimento pr\u00e1tico: passos que funcionam<\/h2>\n<p>Come\u00e7o com uma fase de medi\u00e7\u00e3o limpa, estabele\u00e7o linhas de base e mantenho todas as altera\u00e7\u00f5es pequenas em janelas de tempo curtas para poder <strong>Causas<\/strong> podem ser separados. Em seguida, ativo o irqbalance, verifico a distribui\u00e7\u00e3o autom\u00e1tica e, se necess\u00e1rio, defino as afinidades manuais at\u00e9 que n\u00e3o haja <strong>Pontos de acesso<\/strong> j\u00e1 n\u00e3o s\u00e3o vis\u00edveis. Em seguida, configuro o Multi-Queueue, RSS e - se necess\u00e1rio - RPS\/XPS, sincronizado com NUMA. Atribuo os trabalhadores de aplica\u00e7\u00f5es a n\u00facleos na vizinhan\u00e7a dos seus n\u00facleos IRQ, mas sem colis\u00e3o direta. Por fim, limpo os caminhos do firewall, verifico as tabelas do conntrack e tomo decis\u00f5es conscientes sobre descargas com base em metas de lat\u00eancia.<\/p>\n\n<h2>Exemplo de livro de jogo para lat\u00eancias do p99<\/h2>\n<p>Primeiro, me\u00e7o p95\/p99 atrav\u00e9s de carga representativa e registos seguros de \/proc\/softirqs e \/proc\/net\/softnet_stat para <strong>Gotas<\/strong> e time_squeeze s\u00e3o claramente vis\u00edveis. Em seguida, aumento o netdev_budget ou netdev_budget_usecs passo a passo e mantenho o p99 ap\u00f3s cada altera\u00e7\u00e3o para que eu possa ver a real <strong>Tend\u00eancias<\/strong> reconhecer. Em paralelo, atribuo IRQs a n\u00facleos de um n\u00f3 NUMA e transfiro trabalhadores de aplica\u00e7\u00f5es para vizinhos adequados. Se o p99 continuar a saltar, testo as variantes GRO\/LRO e interrompo os perfis de coalesc\u00eancia, cada um com um caminho de medi\u00e7\u00e3o curto. S\u00f3 quando a distribui\u00e7\u00e3o permanece est\u00e1vel \u00e9 que transfiro a configura\u00e7\u00e3o para fun\u00e7\u00f5es Ansible ou dropins systemd.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vers\u00e3o curta para administradores<\/h2>\n<p>Consigo o maior efeito de alavanca ao <strong>SoftIRQs<\/strong>, or\u00e7amento da NAPI, afinidades de IRQ e threads de aplicativos como um caminho de dados coerente. Eu distribuo o trabalho de rede entre os n\u00facleos, mantenho filas coerentes com NUMA e conecto os trabalhadores de forma sensata para que <strong>Rotas<\/strong> resumir. Defino os offloads deliberadamente e me\u00e7o o jitter em vez de otimizar cegamente o throughput. Para alvos de lat\u00eancia dif\u00edcil, eu confio em polling ocupado e isolamento de CPU, enquanto CPUs de manuten\u00e7\u00e3o interceptam a interfer\u00eancia. Se implementar estes passos de forma disciplinada, obt\u00e9m um d\u00e9bito constante, distribui\u00e7\u00f5es de lat\u00eancia mais estreitas e um ambiente de alojamento que reage de forma previs\u00edvel aos picos de carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Saiba como o softirq cpu hosting com interrup\u00e7\u00f5es linux optimizadas, NAPI e IRQ balancing aumenta o rendimento da sua rede e reduz as lat\u00eancias na opera\u00e7\u00e3o do servidor.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"70","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"softirq cpu","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/19569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}