Capítulo 8. Networking
Com o tempo, pilha de rede do Red Hat Enterprise Linux foi atualizada com inúmeros recursos de otimização automatizadas. Para a maioria das cargas de trabalho, as configurações de rede auto-configurados proporcionam desempenho otimizado.
Na maioria dos casos, problemas de desempenho de rede são realmente causados por um defeito no hardware ou infra-estrutura deficiente. Tais causas estão além do escopo deste documento, os problemas de desempenho e soluções discutidas neste capítulo são úteis na otimização de sistemas perfeitamente funcionais.
Networking é um subsistema delicado, contendo partes diferentes com conexões sensíveis. É por isso que a comunidade open source e Red Hat investem muito trabalho na implementação de formas de otimizam automaticamente o desempenho da rede. Como tal, dado a maioria das cargas de trabalho, você pode nunca precisar reconfigurar a rede para o desempenho.
8.1. Melhorias de Desempenho de Rede
Red Hat Enterprise Linux 6.1 fornece as seguintes melhorias de desempenho de rede:
8.1.1. Receive Packet Steering (RPS)
RPS permite que uma única fila de NIC
rx tenha sua recepção de carga de trabalho softirq distribuída entre diversas CPUs. Isto ajuda a prevenir tráfego em rede de ser afunilado em uma única fila de hardware NIC.
Para permitir um RPS, especificamente os nomes de CPU de alvo em
/sys/class/net/ethX/queues/rx-N/rps_cpus, substituindo ethX pelo nome de dispositivo correspondente do NIC (por exemplo, eth1, eth2) e rx-Npela fila de recepção do NIC especificada. Isto permitirá que as CPUs especificadas no arquivo processem dados de uma fila rx-N em ethX. Ao especificar CPUs, consider o cache affinity da fila [4].
8.1.2. Receive Flow Steering
RFS é uma extensão do RPS, permitindo que o administrador configure uma tabela hash que é preenchido automaticamente quando receber aplicações de dados e são interrogados pela pilha de rede. Isso determina quais aplicativos estão recebendo cada pedaço de dados de rede (com base na fonte: informações sobre a rede de destino).
Com o uso desta informação, a pilha de rede pode agendar a CPU ideal para receber cada pacote. Para configurar RFS, use os seguintes ajustáveis:
/proc/sys/net/core/rps_sock_flow_entries- Isto controla o número máximo de soquetes/fluxos que o kernel pode conduzir em direção a qualquer CPU específica. Isto é um limite compartilhado com todo o sistema.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt- Isto controla o número máximo de soquetes/fluxos que o kernel pode conduzir em direção a qualquer CPU específica. (
rx-N) em um NIC (ethX). Note que o resumo de todos os valores por fila para este ajustável em todos os NICs deve ser igual ou menor do que/proc/sys/net/core/rps_sock_flow_entries.
Ao contrário de RPS, o RFS permite tanto a fila de recebimento e a aplicação de compartilhar a mesma CPU durante o processamento de fluxos de pacotes. Isto pode resultar em melhor desempenho em alguns casos. No entanto, tais melhorias são dependentes de fatores como a hierarquia de cache, a carga de aplicação, e semelhantes.
8.1.3. suporte de getsockopt para thin-streams do TCP
Thin-stream é um termo usado para caracterizar protocolos de transportes onde os aplicativos enviam dados com taxas tão baixas que os mecanismos de retransmissão de protocolo não ficam totalmente saturados. Os aplicativos que utilizam os protocolos thin-stream geralmente transportam via protocolos confiáveis como o TCP; na maioria dos casos, tais aplicativos fornecem serviços sensíveis ao tempo (por exemplo, stock trading, online gaming, sistemas de controle).
Para serviços sensíveis ao tempo, a perda de pacote pode ser devastadora para a qualidade de serviço. Para ajudar a prevenir isto, a chamada
getsockopt foi aprimorada para suportar duas opções extras:
- TCP_THIN_DUPACK
- Este Booleano habilita o disparo dinâmico de retransmissão após um dupACK para thin streams.
- TCP_THIN_LINEAR_TIMEOUTS
- Este Booleano habilita o disparo dinâmico de limite de tempo linear para thin streams.
Ambas opções são ativadas especificamente pelo aplicativo. Para mais informações sobre estas opções, consulte o
file:///usr/share/doc/kernel-doc-versão/Documentation/networking/ip-sysctl.txt. Para mais informações sobre o thin-streams, consulte o file:///usr/share/doc/kernel-doc-versão/Documentation/networking/tcp-thin.txt.
8.1.4. Suporte Transparent Proxy (TProxy)
O kernel pode agora lidar com bound não local IPv4 TCP e soquetes UDP para suportar proxies transparentes. Para habilitar isto, você terá de configurar iptables adequadamente. Você também irá precisar habilitar e configurar o roteamento de política adequadamente.
Para mais informações sobre os proxies transparentes, consulte o
file:///usr/share/doc/kernel-doc-version/Documentation/networking/tproxy.txt.
[4]
Assegurar o cache affinity entre uma CPU e NIC significa configurá-los para compartilhar do mesmo cache L2. Para mais informações, consulte o Seção 8.3, “Visão Geral de Recepção de Pacotes”.
