MTU completo não utilizado com quadros jumbo habilitados

Question

Eu tenho testado para ver se consigo algum benefício de ativar quadros jumbo. Configurei dois servidores Dell R210 idênticos com CPUs E3122 quad core Xeon, 8G de RAM e placas Broadcom NetXtreme II BCM5716 Gigabit Ethernet. Estou executando o Debian Squeeze com o driver de rede bnx2 em ambos os sistemas. Os servidores são conectados de volta a um NIC em uma sub-rede privada, e eu estou usando o outro NIC em ambos para SSH e monitoramento. Eu adicionei os parâmetros de ajuste do SO que eu conheço:

sysctl -w net.core.rmem_max=134217728             
sysctl -w net.core.wmem_max=134217728             
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"  
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"  
sysctl -w net.core.netdev_max_backlog=300000  
sysctl -w net.ipv4.tcp_sack=0  
sysctl -w net.ipv4.tcp_fin_timeout=15  
sysctl -w net.ipv4.tcp_timestamps=0    
ifconfig ethX txqueuelen 300000  
ethtool -K eth1 gso on

Ethtool -k output mostra

rx-checksumming: on  
tx-checksumming: on
scatter-gather: on   
tcp-segmentation-offload: on  
udp-fragmentation-offload: off  
generic-segmentation-offload: on  
generic-receive-offload: on  
large-receive-offload: off  
ntuple-filters: off  
receive-hashing: off

Ambos os servidores estão configurados para quadros jumbo de 9000 bytes via ifconfig ( sudo /sbin/ifconfig eth1 mtu 9000 ) e eu confirmei os MTUs nos dois sistemas via ping ( ping -s 8972 -M do <other IP> ). Quando eu testo transferências em massa com o netperf, o tcpdump confirma que a maioria dos pacotes de dados usa o MTU completo de 9000 bytes, com um tamanho de quadro de 9014.

No entanto, quando eu testo com um aplicativo "real" - configuro o Postgres em um servidor e uso o outro como um cliente, o MTU máximo informado pelo tcpdump e tshark é 2160, mesmo para seleções muito grandes com conjuntos de resultados em execução em megabytes. Eu não sou capaz de fazê-lo subir, apesar de ter tentado o quackery como configurar advmss na rota usando o iproute2.

Pensamentos?

TIA.

    

Answer 1

O Postgres pode não ser a melhor aplicação "real" para empacotar pacotes completos. Com base em um lista de discussão antiga , parece que os desenvolvedores tentaram melhorar o desempenho usando TCP_NODELAY e / ou TCP_CORK (desativando o algoritmo Nagle).

Tente usar um aplicativo diferente, como ...

• HTTP (servidor web em um host, puxe arquivos grandes em outro servidor)
• NFS (montagem com "rsize = 8192, wsize = 8192")
• Exponha seus dados de postgres usando SOAP
• Experimente o MySQL, o DB2 Express, o Oracle XE, o Sybase Anywhere (com pacotes de 4k ou maiores). Se algum outro banco de dados preencher melhor os pacotes jumbo com as mesmas tabelas, dados e consultas, envie um relatório de erros para os desenvolvedores do Postgres.