Como é que o Receive-Side Scaling distribui a carga da rede do servidor doméstico?

O Receive-Side Scaling distribui a carga da rede do servidor doméstico ao distribuir os fluxos recebidos por várias filas de receção da NIC e associar essas filas a diferentes núcleos de CPU. Em vez de um núcleo lidar com quase todas as interrupções de receção e tarefas de protocolo, vários núcleos podem processar ligações independentes em paralelo.

O RSS é mais útil quando o servidor recebe pacotes suficientes para que um núcleo se torne o limite. Não torna um único disco mais rápido, não aumenta a capacidade da rede nem divide um fluxo TCP comum de forma uniforme por todos os núcleos. A sua função é eliminar um gargalo no processamento de pacotes, preservando a ordem dos fluxos.

O Mecanismo Principal: Múltiplas Filas de Receção Alimentam Múltiplos Núcleos

Sem o processamento de receção multi-fila, uma NIC rápida pode entregar trabalho a um caminho de interrupção mais rapidamente do que um núcleo de CPU consegue atender. O uso geral da CPU pode parecer modesto porque os outros núcleos estão ociosos, mas o débito atinge um limite e a latência da rede aumenta no núcleo sobrecarregado.

O RSS usa múltiplas filas de receção para que os fluxos recebidos possam ser tratados em simultâneo. Cada fila gera a sua própria interrupção e caminho de processamento, permitindo ao sistema operativo usar mais dos recursos de CPU já disponíveis.

Isto é importante num servidor doméstico a executar partilha de ficheiros, fluxos de media, backups e aplicações em contentores ao mesmo tempo. Essas ligações independentes fornecem o trabalho paralelo que o RSS necessita; uma ligação 1GbE pouco utilizada pode nunca criar pressão suficiente de pacotes para que a diferença seja visível.

A Hash dos Fluxos Preserva a Ordem Enquanto Distribui as Ligações

A NIC calcula um hash a partir dos campos do cabeçalho do pacote, como endereços de origem e destino, portas e protocolo. Uma tabela de indireção mapeia esse hash para uma fila de receção. Os pacotes do mesmo fluxo normalmente chegam à mesma fila, evitando que o processamento paralelo desorganize esse fluxo.

A relação entre RSS, afinidade IRQ e RPS determina onde o trabalho é realmente executado no Linux. O RSS de hardware escolhe uma fila de receção; a afinidade de interrupção liga essa fila a uma CPU; o encaminhamento por software pode redistribuir o trabalho do protocolo mais tarde quando as filas de hardware são limitadas.

A hash equilibra muitos fluxos estatisticamente, não perfeitamente. Alguns fluxos pesados podem colidir numa fila, e um fluxo dominante pode permanecer ligado a um único núcleo. Por isso, as observações por núcleo e por fila são mais úteis do que assumir que uma CPU multi-núcleo garante uma carga de rede uniforme.

Mais Filas Podem Trocar Alívio de Gargalo por Sobrecarga da CPU

Aumentar o número de filas cria mais oportunidades para paralelismo, mas também gera mais interrupções, trabalho de agendamento e movimentação de cache. O número ideal depende da capacidade da NIC, topologia da CPU, taxa de tráfego e se as aplicações que consomem pacotes correm perto do processamento de receção.

Uma explicação prática da saturação de receção num único núcleo mostra porque a percentagem total da CPU pode esconder o verdadeiro limite. O teste útil é verificar se um núcleo está preso por interrupções ou trabalho softirq enquanto os outros núcleos têm margem.

O RSS também pode aumentar a sobrecarga quando o tráfego é demasiado leve para o justificar. A distribuição paralela de pacotes melhora a escala, mas a colocação das filas e a localidade fluxo-núcleo ainda afetam a eficiência. Por isso, ativar todas as filas possíveis não é uma otimização universal.

Como o RSS Altera um Gargalo num Servidor Doméstico

O RSS ajuda quando o caminho de receção está limitado pela CPU: um núcleo mostra alta carga de processamento de rede, vários clientes estão ativos e o armazenamento ainda tem capacidade. Não ajuda quando a ligação Ethernet está saturada, os discos não conseguem suportar a carga, a encriptação domina o tempo da CPU ou uma aplicação serializa todos os pedidos.

Compare os contadores das filas da NIC, a carga de interrupções por núcleo, o débito e a latência da aplicação antes e depois de uma alteração controlada. Uma verificação mais ampla de gargalos em servidores domésticos ajuda a evitar que uma alteração na configuração da rede esconda uma limitação no armazenamento, memória ou computação.

Perguntas Frequentes

O RSS divide uma ligação TCP por todos os núcleos?

Normalmente não. O RSS mantém os pacotes de um fluxo na mesma fila para preservar a ordem. O benefício do escalamento é mais claro quando vários fluxos independentes podem ser distribuídos por várias filas.

O RSS é útil num servidor doméstico 1GbE?

Pode ser, especialmente com muitos pacotes pequenos ou uma CPU de baixo consumo, mas muitos sistemas conseguem processar 1GbE num único núcleo. Meça a carga por núcleo antes de considerar o RSS como a funcionalidade de desempenho em falta.

O RSS e o RPS são a mesma coisa?

Não. O RSS direciona pacotes no hardware da NIC para filas de receção, enquanto o Receive Packet Steering realiza uma etapa relacionada de distribuição em software. Podem complementar-se quando o número de filas de hardware é limitado.