{"id":21057,"date":"2026-08-27T11:49:04","date_gmt":"2026-08-27T09:49:04","guid":{"rendered":"https:\/\/webhosting.de\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/"},"modified":"2026-08-27T11:49:04","modified_gmt":"2026-08-27T09:49:04","slug":"escalabilidade-do-lado-da-rececao-rss-10-g-25-g-otimizacao-do-servidor-linux-taxa-de-bits","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/","title":{"rendered":"Receive Side Scaling a 10 e 25 Gbit\/s: otimiza\u00e7\u00e3o do desempenho para redes de servidores Linux modernas"},"content":{"rendered":"<p><strong>Receive Side Scaling<\/strong> distribui o tr\u00e1fego de rede de forma direcionada por v\u00e1rias n\u00facleos, atrav\u00e9s de liga\u00e7\u00f5es de 10 e 25 Gbit\/s, para que os servidores Linux processem elevadas taxas de d\u00e9bito com baixa lat\u00eancia. Vou mostrar, de forma pr\u00e1tica, como ativo o RSS, que <strong>Tacos<\/strong> na pasta do Core, evitando assim gargalos nas interrup\u00e7\u00f5es e nos acertos de cache.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Vou resumir brevemente os aspetos mais importantes, para que possas planear rapidamente os pr\u00f3ximos passos.<\/p>\n<ul>\n  <li><strong>Distribui\u00e7\u00e3o da carga<\/strong>: Os pacotes s\u00e3o distribu\u00eddos por v\u00e1rios n\u00facleos atrav\u00e9s de v\u00e1rias filas.<\/li>\n  <li><strong>Localiza\u00e7\u00e3o da cache<\/strong>: Um fluxo permanece sempre na mesma fila.<\/li>\n  <li><strong>Hashing<\/strong>: O hash de quartetos distribui os fluxos de forma uniforme pelas filas.<\/li>\n  <li><strong>afinidade<\/strong>: O mapeamento espec\u00edfico de IRQ reduz as lat\u00eancias.<\/li>\n  <li><strong>Escalonamento<\/strong>: A partir de 10\/25 Gbit\/s, a tecnologia RSS garante um elevado d\u00e9bito.<\/li>\n<\/ul>\n<p>Estes pontos est\u00e3o interligados e sustentam a <strong>Desempenho<\/strong> com base em cargas de trabalho reais. Dou prioridade, em primeiro lugar, ao n\u00famero correto de filas e, em seguida, ao <strong>CPU<\/strong>-Afinidade. Em seguida, verifico os par\u00e2metros de hash e os ajustes finos.<\/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\/08\/servernetzwerk-performance-2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o Receive Side Scaling oferece<\/h2>\n\n<p>O RSS divide a rece\u00e7\u00e3o de pacotes em v\u00e1rias partes <strong>Filas de rece\u00e7\u00e3o<\/strong>, que atribuo a n\u00facleos espec\u00edficos da CPU, para que nenhum n\u00facleo isolado se torne um gargalo. Isto diminui os picos de interrup\u00e7\u00f5es duras e suaviza o processamento atrav\u00e9s de SoftIRQs, o que reduz os picos de lat\u00eancia e aumenta o d\u00e9bito. Cada fila aciona as suas pr\u00f3prias interrup\u00e7\u00f5es, que atribuo de forma fixa a n\u00facleos espec\u00edficos, para manter a consist\u00eancia dos percursos de dados. Esta consist\u00eancia promove a <strong>Cache<\/strong>-Localiza\u00e7\u00e3o, porque um fluxo incide sempre no mesmo n\u00facleo. \u00c9 precisamente esta intera\u00e7\u00e3o que, com taxas de PPS elevadas, se traduz diretamente numa efici\u00eancia mensur\u00e1vel.<\/p>\n\n<h2>\u00c9 assim que o RSS funciona, do ponto de vista t\u00e9cnico<\/h2>\n\n<p>A NIC forma, a partir do IP de origem\/destino e da porta de origem\/destino, um <strong>Haxixe<\/strong> e utiliza-o como \u00edndice para a tabela de indire\u00e7\u00e3o, que aponta para as filas. Desta forma, os pacotes de um fluxo acabam sempre na mesma fila e permanecem, assim, ligados ao mesmo n\u00facleo. Os diferentes fluxos distribuem-se uniformemente, desde que as chaves de hash e os campos de protocolo estejam configurados de forma adequada. O trabalho \u00e9, assim, transferido para perto da <strong>Hardware<\/strong>, o que faz com que o kernel tenha de realizar menos ajustes de equil\u00edbrio e reduz a sobrecarga. \u00c9 exatamente isso que pretendo, para manter baixo o processamento de pacotes por n\u00facleo em 10G\/25G.<\/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\/08\/linuxnetzwerke_tuning4683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por que \u00e9 que o RSS a partir de 10 e 25 Gbit\/s \u00e9 importante<\/h2>\n\n<p>A 1 Gbit\/s, muitas vezes basta um \u00fanico <strong>N\u00facleo<\/strong> a carga de pacotes, mas a partir dos 10 Gbit\/s o equil\u00edbrio altera-se rapidamente. Os pacotes pequenos fazem aumentar o n\u00famero de PPS, o que faz com que um n\u00facleo atinja rapidamente 100 por cento da carga e ocorram perdas de pacotes. \u00c9 precisamente nessa altura que o RSS funciona como um multiplicador da largura de banda \u00fatil. Distribuo a carga por v\u00e1rios <strong>N\u00facleos<\/strong>, reduz as mudan\u00e7as de contexto e mant\u00e9m as curvas de lat\u00eancia mais est\u00e1veis. O resultado: s\u00f3 com um RSS limpo \u00e9 que a taxa de transfer\u00eancia real se aproxima da taxa de liga\u00e7\u00e3o.<\/p>\n\n<h2>Configurar o RSS no servidor Linux<\/h2>\n\n<p>No Linux, controlo o RSS principalmente atrav\u00e9s de <strong>ferramenta eletr\u00f3nica<\/strong>, op\u00e7\u00f5es do controlador e sysfs, para que as capacidades da NIC sejam efetivamente aproveitadas. Primeiro, leio o n\u00famero m\u00e1ximo de canais de rece\u00e7\u00e3o (RX) e, em seguida, defino um n\u00famero de filas adequado \u00e0 CPU. Em seguida, verifico o hash RSS para TCP\/UDP e, opcionalmente, para VLAN ou tunelamento, para que os perfis de carga se mantenham distribu\u00eddos de forma adequada. Para o ru\u00eddo de fundo da distribui\u00e7\u00e3o de interrup\u00e7\u00f5es, o que me ajuda \u00e9 <a href=\"https:\/\/webhosting.de\/pt\/configurar-o-irq-balance-no-linux-num-servidor\/\">Equil\u00edbrio de IRQ<\/a>, embora prefira marcar manualmente as filas cr\u00edticas. \u00c9 assim que as associo <strong>Tacos<\/strong> adaptar-se estreitamente \u00e0 topologia do anfitri\u00e3o e impedir desloca\u00e7\u00f5es indesej\u00e1veis.<\/p>\n\n<h2>Tabela de indire\u00e7\u00e3o, chave RSS e ajuste fino do hash: comandos concretos<\/h2>\n\n<p>Primeiro, verifico a distribui\u00e7\u00e3o atual e a chave da placa de rede:<\/p>\n<pre><code>ethtool -x eth0 # Mostrar a tabela de indire\u00e7\u00e3o (filas de rece\u00e7\u00e3o) e a chave RSS\nethtool -n eth0 rx-flow-hash tcp4\nethtool -n eth0 rx-flow-hash udp4\n<\/code><\/pre>\n<p>Para uma distribui\u00e7\u00e3o limpa e uniforme, defino a tabela de indire\u00e7\u00e3o para o n\u00famero desejado de filas. Com 16 filas, opto por um mapeamento uniforme:<\/p>\n<pre><code>ethtool -X eth0 equal 16  Distribui\u00e7\u00e3o # uniformemente por 16 filas\n<\/code><\/pre>\n<p>Se for necess\u00e1rio, ajusto os campos de hash. Para o TCP4 com quadruplas (s=IP de origem, d=IP de destino, f=porta de origem, n=porta de destino):<\/p>\n<pre><code>ethtool -N eth0 rx-flow-hash tcp4 sdfn\nethtool -N eth0 rx-flow-hash udp4 sdfn\nethtool -N eth0 rx-flow-hash tcp6 sdfn\nethtool -N eth0 rx-flow-hash udp6 sdfn\n<\/code><\/pre>\n<p>Alguns controladores tamb\u00e9m permitem definir uma chave RSS personalizada (por exemplo, para uma melhor distribui\u00e7\u00e3o em casos espec\u00edficos):<\/p>\n<pre><code>ethtool -X eth0 hkey   # apenas se o controlador\/NIC o suportar\n<\/code><\/pre>\n\n<h2>Definir corretamente a afinidade da CPU e o NUMA<\/h2>\n\n<p>Mapeio cada fila de rece\u00e7\u00e3o atrav\u00e9s de <strong>Afinidade IRQ<\/strong> atribuir a n\u00facleos dedicados, tendo em conta o NUMA, para que os dados percorram uma dist\u00e2ncia curta atrav\u00e9s do controlador de mem\u00f3ria. Se a NIC estiver no N\u00f3 0, tamb\u00e9m atribuo as filas principais a n\u00facleos no N\u00f3 0 e coloco as cargas de trabalho nas proximidades. Esta proximidade reduz os acessos remotos e diminui significativamente as lat\u00eancias de mem\u00f3ria. Para tal, \u00e9 \u00fatil dispor de um perfil para filas produtivas, bem como de n\u00facleos separados para tarefas de gest\u00e3o e de descarregamento. Quem quiser aprofundar o assunto encontrar\u00e1 orienta\u00e7\u00f5es para o ajuste fino em <a href=\"https:\/\/webhosting.de\/pt\/servidor-irq-afinidade-multicore-rede-otimizacao-desempenho\/\">Afinidade IRQ<\/a>, no que diz respeito ao planeamento por <strong>N\u00facleo<\/strong> simplificado.<\/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\/08\/linux-server-network-tuning-2478.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guia pr\u00e1tico sobre a afinidade de IRQ: das IRQ \u00e0 liga\u00e7\u00e3o est\u00e1vel ao n\u00facleo<\/h2>\n\n<p>Primeiro, determino quais s\u00e3o os IRQs associados \u00e0s filas de rece\u00e7\u00e3o e, em seguida, atribuo-lhes uma liga\u00e7\u00e3o fixa:<\/p>\n<pre><code>grep -E \"eth0.*Rx\" \/proc\/interrupts\ncat \/sys\/class\/net\/eth0\/device\/numa_node\n<\/code><\/pre>\n<p>Defino a atribui\u00e7\u00e3o atrav\u00e9s de <code>smp_affinity_list<\/code>, para n\u00e3o ter de fazer c\u00e1lculos com m\u00e1scaras hexadecimais. Exemplo: filas RX 0\u20137 nos n\u00facleos 2\u20139:<\/p>\n<pre><code>Exemplo #: Atribuir IRQs aos n\u00facleos 2-9 (uma linha por IRQ)\necho 2  &gt; \/proc\/irq\/\/smp_affinity_list\necho 3  &gt; \/proc\/irq\/\/smp_affinity_list\necho 4  &gt; \/proc\/irq\/\/smp_affinity_list\n...\necho 9  &gt; \/proc\/irq\/\/smp_affinity_list\n<\/code><\/pre>\n<p>Importante: o MSI-X tem de estar ativo para que cada fila tenha as suas pr\u00f3prias interrup\u00e7\u00f5es. Se utilizar a atribui\u00e7\u00e3o manual de pinos, bloqueio <code>equil\u00edbrio do Iraque<\/code> para estes IRQs (por exemplo, atrav\u00e9s de uma lista negra) ou desative o servi\u00e7o especificamente em hosts com layout est\u00e1tico. Verifico tamb\u00e9m o NUMA com <code>lscpu<\/code> e a atribui\u00e7\u00e3o PCIe, para n\u00e3o criar percursos entre n\u00f3s.<\/p>\n\n<h2>Configura\u00e7\u00e3o de hash e protocolos<\/h2>\n\n<p>Defino os campos hash de forma a que os verdadeiros <strong>Tr\u00e1fego<\/strong>-Distribuir bem os padr\u00f5es, em vez de concentr\u00e1-los em poucas filas. Para TCP\/UDP, utilizo o quadruplo; para IPv6, fa\u00e7o o mesmo, enquanto que, no caso de VXLAN ou GRE, tenho em conta campos adicionais de encapsulamento. Algumas placas de rede (NICs) oferecem chaves de hash configur\u00e1veis, que adapto \u00e0 carga de trabalho dominante. Assim que deteto aglomera\u00e7\u00e3o de carga em filas espec\u00edficas, reajusto a sele\u00e7\u00e3o de hash. Este passo demora pouco tempo, mas evita uma <strong>desequil\u00edbrio<\/strong> com um elevado n\u00famero de liga\u00e7\u00f5es.<\/p>\n\n<h2>Coalesc\u00eancia de interrup\u00e7\u00f5es e PPS<\/h2>\n\n<p>Combino o RSS com um uso moderado <strong>Coalesc\u00eancia de interrup\u00e7\u00f5es<\/strong>, para agrupar o tr\u00e1fego com elevado consumo de PPS em lotes mais f\u00e1ceis de gerir. Isto reduz a sobrecarga das interrup\u00e7\u00f5es, mas n\u00e3o pode prejudicar a lat\u00eancia de servi\u00e7os mais sens\u00edveis. Por isso, medo os tempos de ida e volta e altero os valores de coalesc\u00eancia gradualmente. Quem gere cargas de armazenamento ou de c\u00f3pia de seguran\u00e7a pode agrupar de forma mais significativa do que no caso das APIs de camada 7 ou do VoIP. Em suma, eu equilibro <strong>Lat\u00eancia<\/strong> em fun\u00e7\u00e3o do caudal, at\u00e9 que ambos estejam em equil\u00edbrio.<\/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\/08\/performance_tuning_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>A coalesc\u00eancia na pr\u00e1tica: perfis e pontos de medi\u00e7\u00e3o<\/h2>\n\n<p>Come\u00e7o com valores predefinidos moderados e vou ajustando at\u00e9 chegar ao ideal para cada carga de trabalho. Tr\u00eas perfis iniciais comprovados:<\/p>\n<ul>\n  <li>API\/Baixa lat\u00eancia: <code>rx-usecs 2\u20136<\/code>, <code>rx-frames 16\u201332<\/code>, desativar a adapta\u00e7\u00e3o<\/li>\n  <li>Vers\u00e1til: <code>rx-usecs 8\u201316<\/code>, <code>rx-frames 32\u201364<\/code>, adapt\u00e1vel a<\/li>\n  <li>A granel\/Armazenamento: <code>24\u201348 rx-usecs<\/code>, <code>rx-frames 128\u2013256<\/code>, adapt\u00e1vel a<\/li>\n<\/ul>\n<pre><code>ethtool -c eth0\nethtool -C eth0 rx-usecs 12 rx-frames 64 adaptive-rx on\n<\/code><\/pre>\n<p>Para isso, medi as lat\u00eancias p95\/p99, o PPS, a carga da CPU por n\u00facleo e as retransmiss\u00f5es. Assim que detetar um aumento da vari\u00e2ncia na API\/VoIP, procedo da seguinte forma: <code>rx-usecs<\/code> novamente para baixo. No que diz respeito ao armazenamento, prefiro escalar atrav\u00e9s dos fotogramas para poupar interrup\u00e7\u00f5es.<\/p>\n\n<h2>RSS em ambientes de 10 Gbit<\/h2>\n\n<p>Nas placas de rede de 10G, costumo trabalhar com 8 a 16 <strong>Tacos<\/strong> por porta, desde que a CPU disponha de n\u00facleos suficientes. Desta forma, os servidores Web, os gateways de armazenamento e os anfitri\u00f5es de virtualiza\u00e7\u00e3o escalam de forma eficiente atrav\u00e9s de v\u00e1rias liga\u00e7\u00f5es paralelas. Atribuo as filas principais a n\u00facleos livres e, em seguida, me\u00e7o o PPS, a lat\u00eancia e as retransmiss\u00f5es. Se ocorrerem perdas de pacotes, verifico a coalesc\u00eancia, o hash e a utiliza\u00e7\u00e3o de cada fila. Depois, fa\u00e7o o ajuste fino da <strong>afinidade<\/strong>, at\u00e9 que a carga de trabalho pare\u00e7a uniforme.<\/p>\n\n<h2>RSS em configura\u00e7\u00f5es de 25 Gbit e Multi-25G<\/h2>\n\n<p>A 25 Gbit\/s, o PPS e a carga do barramento aumentam, raz\u00e3o pela qual eu <strong>NUMA<\/strong>- Estou mais atento \u00e0 gest\u00e3o de filas e \u00e0 utiliza\u00e7\u00e3o de mecanismos de descarregamento. O Large Receive Offload (LRO) ou o RSC podem reduzir a press\u00e3o de pacotes na pilha, desde que as aplica\u00e7\u00f5es o permitam. Al\u00e9m disso, verifico as pistas PCIe para excluir poss\u00edveis estrangulamentos fora da rede. Em hosts com v\u00e1rias liga\u00e7\u00f5es de 25G, separo as filas e a afinidade rigorosamente de acordo com as tarefas e os n\u00f3s. Assim, utilizo <strong>Largura de banda<\/strong> e n\u00facleos de forma eficiente, sem incorrer em tr\u00e1fego entre n\u00f3s.<\/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\/08\/linuxnetztuning_7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detalhes sobre hardware\/drivers: o que tenho em conta<\/h2>\n\n<p>Nem todas as placas de rede (NIC) funcionam da mesma forma. As gera\u00e7\u00f5es da Intel (por exemplo, ixgbe, i40e, ice) oferecem funcionalidades como o Flow Director\/ATR, que associam fluxos de forma espec\u00edfica a filas \u2013 o que \u00e9 \u00fatil quando pretendo nivelar pontos de congestionamento. A Mellanox mlx5 suporta aRFS a n\u00edvel de hardware, o que reduz a carga da CPU quando a pilha atende a muitos sockets. Decido caso a caso se ativo estas funcionalidades e avalio se melhoram a distribui\u00e7\u00e3o. Em sistemas de encaminhamento\/NAT, costumo desativar o LRO e optar pelo GRO para manter a consist\u00eancia dos cabe\u00e7alhos; em cargas de trabalho exclusivamente de servidor, o LRO\/GRO pode ajudar a atenuar a press\u00e3o de PPS. S\u00e3o tamb\u00e9m importantes vetores MSI-X suficientes por fila e vers\u00f5es de firmware corretas.<\/p>\n\n<h2>RSS na virtualiza\u00e7\u00e3o e nos contentores<\/h2>\n\n<p>No hipervisor, combino os recursos f\u00edsicos <strong>RSS<\/strong>-Filas com vNICs compat\u00edveis com m\u00faltiplas filas, como o virtio-net, para que os convidados n\u00e3o enfrentem estrangulamentos artificiais. Presto aten\u00e7\u00e3o ao \u00abCPU-pinning\u00bb das m\u00e1quinas virtuais e defino a proximidade NUMA das suas vCPUs em rela\u00e7\u00e3o \u00e0 NIC f\u00edsica. Desta forma, os dados permanecem localmente e o anfitri\u00e3o paga menos pelos acessos \u00e0 mem\u00f3ria. No caso dos contentores, associo os pods cr\u00edticos a n\u00facleos adequados e mantenho as filas do anfitri\u00e3o livres de carga indesejada. Esta organiza\u00e7\u00e3o aumenta a <strong>Efici\u00eancia<\/strong> no caso dos microsservi\u00e7os, onde surgem muitos pequenos fluxos.<\/p>\n\n<h2>Como utilizar corretamente o SR-IOV e o VF-RSS<\/h2>\n\n<p>Com o SR-IOV, atribuo \u00e0s m\u00e1quinas virtuais (VMs) as suas pr\u00f3prias VF, que, por sua vez, podem disponibilizar v\u00e1rias filas e RSS. Planeio um n\u00famero suficiente de VF por porta, tenho em conta a capacidade MSI-X e mapeio os IRQs das VF na VM de acordo com as respetivas vCPUs. Em m\u00e1quinas virtuais Linux, ativo explicitamente o Multi-Queue; caso contr\u00e1rio, a vNIC permanece frequentemente em modo de n\u00edvel \u00fanico:<\/p>\n<pre><code># no sistema convidado (exemplo do virtio-net)\nethtool -l eth0\nethtool -L eth0 combined 4\n<\/code><\/pre>\n<p>Distribuo os hosts com v\u00e1rias VFs estritamente por n\u00f3 NUMA e por carga de trabalho, para que as m\u00e1quinas virtuais n\u00e3o interfiram entre si nas mesmas vias f\u00edsicas de rece\u00e7\u00e3o.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas<\/h2>\n\n<p>Eu monitorizo a utiliza\u00e7\u00e3o por <strong>Fila de espera<\/strong>, n\u00facleos individuais, perdas de pacotes e retransmiss\u00f5es, para detetar desequil\u00edbrios numa fase inicial. Quando um n\u00facleo fica sobrecarregado e os outros permanecem ociosos, muitas vezes a afinidade ou o n\u00famero de filas n\u00e3o est\u00e1 correto. Nesses casos, verifico os campos de hash, as m\u00e1scaras de IRQ e os valores de coalesc\u00eancia, um a um. Al\u00e9m disso, analiso o <a href=\"https:\/\/webhosting.de\/pt\/softirq-cpu-hosting-otimizacao-do-debito-da-rede-datacenter\/\">Carga de SoftIRQ<\/a>, porque fornece ind\u00edcios de efeitos de deslocamento. S\u00f3 quando esses sinais parecerem est\u00e1veis \u00e9 que aumento o tr\u00e1fego ou expando <strong>Tacos<\/strong> continuar.<\/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\/08\/servernetzwerk-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS, RFS e XPS: complementos de software para o RSS<\/h2>\n\n<p>Se uma placa de rede tiver poucas filas ou se eu utilizar bonding\/tunneling, complemento o RSS com <strong>RPS<\/strong> (Receive Packet Steering) e <strong>RFS<\/strong> (Receive Flow Steering). O RPS distribui os SoftIRQs pelos n\u00facleos, enquanto o RFS associa os fluxos ao n\u00facleo no qual o socket correspondente est\u00e1 ativo. Ativo ambos de forma seletiva:<\/p>\n<pre><code># Aumentar globalmente o n\u00famero de entradas de fluxo (RFS)\necho 32768 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\n\n# Definir CPUs por fila de rece\u00e7\u00e3o (RPS) (m\u00e1scara de exemplo, adaptar!)\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_cpus; do echo ffff &gt; \"$f\"; done\n\nConfigurar a tabela de fluxo da fila de rece\u00e7\u00e3o # para RFS\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_flow_cnt; do echo 4096 &gt; \"$f\"; done\n<\/code><\/pre>\n<p>No lado do TX, utilizo <strong>XPS<\/strong> (Transmit Packet Steering), para que os pacotes de sa\u00edda sejam enviados pelo n\u00facleo que os gerou:<\/p>\n<pre><code>for f in \/sys\/class\/net\/eth0\/queues\/tx-*\/xps_cpus; do echo ffff &gt; \"$f\"; done\n<\/code><\/pre>\n<p>O RPS\/RFS\/XPS consomem algum recurso da CPU, mas ajudam quando me faltam filas a n\u00edvel de hardware ou quando pretendo manter rigorosamente a localidade do socket.<\/p>\n\n<h2>Desempenho de fluxo \u00fanico, GRO\/TSO e Busy-Polling<\/h2>\n\n<p>Um \u00fanico fluxo permanece ligado a um n\u00facleo por uma boa raz\u00e3o. Se pretender aumentar a largura de banda de um \u00fanico fluxo, recorro a offloads (GRO\/TSO), a uma frequ\u00eancia elevada do n\u00facleo e a uma coalesc\u00eancia adequada. Para percursos em que a lat\u00eancia \u00e9 cr\u00edtica, pode <strong>Sondagem ocupada<\/strong> ajudar:<\/p>\n<pre><code>Definir o valor de # para um valor baixo e efetuar a medi\u00e7\u00e3o\nsysctl -w net.core.busy_read=25\nsysctl -w net.core.busy_poll=25\n<\/code><\/pre>\n<p>O Busy-Polling reduz as mudan\u00e7as de contexto, mas consome tempo de CPU. S\u00f3 o ativo nos casos em que as lat\u00eancias p99 s\u00e3o importantes e valido sempre os efeitos na carga total e na lat\u00eancia de cauda. Normalmente, mantenho o GRO ativado nos servidores; quanto ao LRO, utilizo-o consoante a fun\u00e7\u00e3o; no caso das \u00abmiddleboxes\u00bb, opto por uma abordagem conservadora, para n\u00e3o interferir com o processamento de cabe\u00e7alhos e a consist\u00eancia do hash.<\/p>\n\n<h2>Recomenda\u00e7\u00f5es e exemplos: filas, afinidade, comandos<\/h2>\n\n<p>Como ponto de partida, escolho um n\u00famero de filas que corresponda \u00e0 <strong>CPU<\/strong> ajuste, observe depois a carga por fila e v\u00e1 ajustando gradualmente. Com 10G, muitas vezes bastam 8 a 16 filas; com 25G, costumo definir um n\u00famero mais elevado, desde que haja n\u00facleos dispon\u00edveis. Para a afinidade, utilizo m\u00e1scaras claras por IRQ, para facilitar a an\u00e1lise posterior dos percursos. A tabela seguinte fornece valores de refer\u00eancia concisos, que posteriormente verifico atrav\u00e9s de medi\u00e7\u00f5es. S\u00f3 os resultados das medi\u00e7\u00f5es determinam se eu <strong>mais<\/strong> aumentar ou diminuir.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Velocidade da liga\u00e7\u00e3o<\/th>\n      <th>Filas RX t\u00edpicas<\/th>\n      <th>Comandos de exemplo<\/th>\n      <th>Notas<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>10 Gbit\/s<\/td>\n      <td>8-16<\/td>\n      <td><code>ethtool -l eth0<\/code> | <code>ethtool -L eth0 rx 16<\/code><\/td>\n      <td><strong>Coalesc\u00eancia<\/strong> manter a intensidade moderada, verificar a lat\u00eancia L7<\/td>\n    <\/tr>\n    <tr>\n      <td>25 Gbit\/s<\/td>\n      <td>16\u201332+<\/td>\n      <td><code>grep . \/proc\/interrupts<\/code> | M\u00e1scaras de IRQ por <code>eco<\/code><\/td>\n      <td><strong>NUMA<\/strong> ter em conta, verificar as pistas PCIe<\/td>\n    <\/tr>\n    <tr>\n      <td>Multi-25G<\/td>\n      <td>Por porta, separadamente<\/td>\n      <td>Ativar o vNIC Multi-Queue (por exemplo, virtio)<\/td>\n      <td>Filas por n\u00facleos e <strong>Cargas de trabalho<\/strong> dividir<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Estes valores de refer\u00eancia constituem apenas o ponto de partida, n\u00e3o o objetivo, uma vez que as cargas de trabalho variam consideravelmente. Registo as altera\u00e7\u00f5es, fa\u00e7o medi\u00e7\u00f5es antes e depois do ajuste e, fora isso, mantenho o ambiente inalterado. Assim que o sistema se mantiver est\u00e1vel sob carga de produ\u00e7\u00e3o, congelo a configura\u00e7\u00e3o. Posteriormente, repito as medi\u00e7\u00f5es ap\u00f3s atualiza\u00e7\u00f5es do kernel ou dos controladores. Desta forma, mantenho-me fiel a <strong>RSS<\/strong> Em bom caminho e com resultados seguros e reproduz\u00edveis.<\/p>\n\n<h2>Dificuldades t\u00edpicas e medidas para as contornar<\/h2>\n\n<p>Muito poucos <strong>Tacos<\/strong> Sobrecarregam n\u00facleos individuais; em n\u00famero excessivo, aumentam a carga administrativa e prejudicam a taxa de acertos na cache. Uma afinidade mal definida redireciona as interrup\u00e7\u00f5es para n\u00facleos j\u00e1 sobrecarregados ou para n\u00f3s NUMA incorretos. Al\u00e9m disso, um hash inadequado faz com que fluxos dominantes entupam as filas. Resolvo isto passo a passo: ajustar o n\u00famero de filas, corrigir a afinidade, expandir os campos de hash, afinar a coalesc\u00eancia. Documento cada altera\u00e7\u00e3o com <strong>M\u00e9tricas<\/strong>, antes de passar para a alavanca seguinte.<\/p>\n\n<h2>Cen\u00e1rios pr\u00e1ticos<\/h2>\n\n<p>Um servidor de armazenamento com 10G beneficia rapidamente de 8\u201312 <strong>Tacos<\/strong> al\u00e9m de uma coalesc\u00eancia moderada, para garantir que as transfer\u00eancias em massa decorram sem problemas. Um servidor de API com um elevado n\u00famero de liga\u00e7\u00f5es necessita frequentemente de campos de hash mais refinados e de uma menor lat\u00eancia nas interrup\u00e7\u00f5es. Os anfitri\u00f5es de virtualiza\u00e7\u00e3o beneficiam significativamente quando o vNIC Multi-Queue est\u00e1 ativo no lado do convidado e se adapta \u00e0 configura\u00e7\u00e3o do anfitri\u00e3o. As cargas de trabalho em contentores funcionam melhor quando os pods cr\u00edticos s\u00e3o executados perto da NIC e da mem\u00f3ria NUMA. Alargo estes padr\u00f5es consoante a situa\u00e7\u00e3o, ao <strong>PPS<\/strong>, compare as retransmiss\u00f5es e a distribui\u00e7\u00e3o das filas.<\/p>\n\n<h2>As plataformas de alto desempenho como vantagem<\/h2>\n\n<p>Configura\u00e7\u00f5es de alojamento com <strong>RSS<\/strong>, as placas de rede com m\u00faltiplas filas (Multi-Queue-NICs) e uma afiniidade bem definida proporcionam reservas percet\u00edveis em picos de carga. Quem estiver a avaliar ofertas de servidores deve informar-se especificamente sobre a capacidade de m\u00faltiplas filas, o NUMA-Pinning e a monitoriza\u00e7\u00e3o. Um fornecedor que implemente visivelmente estes aspetos alcan\u00e7a frequentemente curvas de d\u00e9bito visivelmente melhores. Para solu\u00e7\u00f5es de servidores e alojamento de alto desempenho, recomendo claramente a webhoster.de. Esta orienta\u00e7\u00e3o compensa em <strong>Desempenho<\/strong> e estabilidade, especialmente quando h\u00e1 muitos fluxos paralelos.<\/p>\n\n<h2>Resumo para a pr\u00e1tica<\/h2>\n\n<p>Eu ativo <strong>Receber<\/strong> Side Scaling: defina um n\u00famero razo\u00e1vel de filas, atribua IRQs aos n\u00facleos adequados e verifique a configura\u00e7\u00e3o do hash. Em seguida, otimizo o coalescing em fun\u00e7\u00e3o da lat\u00eancia, presto aten\u00e7\u00e3o \u00e0 proximidade NUMA e distribuo as cargas de trabalho de forma consistente. Na virtualiza\u00e7\u00e3o, utilizo o Multi-Queue at\u00e9 aos sistemas convidados e mantenho o pinning e a afinidade sincronizados. As medi\u00e7\u00f5es relativas a PPS, carga das filas, retransmiss\u00f5es e lat\u00eancia determinam o pr\u00f3ximo passo. Quem proceder desta forma tira o m\u00e1ximo partido de 10G e 25G na pr\u00e1tica, mantendo <strong>Lat\u00eancia<\/strong> no \u00e2mbito deste contexto e obt\u00e9m, de forma fi\u00e1vel, um retorno da rede.<\/p>","protected":false},"excerpt":{"rendered":"<p>O Receive Side Scaling otimiza redes de 10G e 25G, distribuindo os pacotes por v\u00e1rios n\u00facleos da CPU. Descubra como configurar o RSS num servidor Linux e, assim, tirar o m\u00e1ximo partido do desempenho da sua configura\u00e7\u00e3o. Foco: Receive Side Scaling em ambientes de alta velocidade.<\/p>","protected":false},"author":1,"featured_media":21050,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21057","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":"159","_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":"receive side scaling","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":"21050","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21057","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=21057"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21050"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}