Tamanho do pacote de rede na string de conexão do sql server para melhorar a taxa de transferência

Question

Temos uma tarefa de carregamento de dados que move uma quantidade relativamente grande de dados pela rede entre dois servidores sql. os servidores estão na mesma sub-rede e há apenas uma alternância entre eles. os dados consistem em vários campos varchar grandes mais um campo xml.

Para aumentar o rendimento. Eu tentei alterar o tamanho do pacote de rede do padrão 4096 para 32627 na seqüência de conexão; No entanto, não parece estar ajudando o desempenho. Eu suspeito que o problema é que, embora nós um correndo gig Ethernet, "jumbo frames" não estão habilitados.

Para confirmar isso, eu tentei dois testes de ping:

ping -l 1400 -f pdbsql01dul

Obras

ping -l 4096 -f pdbsql01dul

O pacote precisa ser fragmentado, mas o DF é definido.

como você pode ver, o maior tamanho de pacote parece estar por volta de 1400

A minha pergunta é, se Jumbo frames são ~ 8096, existe algum benefício em configurar o tamanho do pacote de rede maior do que isso?

Isso muda se a conexão for local para o servidor em questão?

    

Answer 1

O que precisa acontecer é que a configuração de MTU na rede ethernet precisa ser aumentada de 1500 para algo ao norte de 4096. Essas configurações são normalmente definidas na página de configurações do Driver. Para uma boa rede, você realmente quer que todos os dispositivos (incluindo todos os switches ethernet) na mesma ethernet tenham a mesma configuração de MTU.

Configuração do Jumbo Frame em um dos meus servidores http://sysadmin1138.net/images/jumbo-setting.png

É onde você mudaria isso em um dos meus servidores.

Isso pode ajudar? Certamente pode. Menos fragmentação de pacotes significa menos trabalho na pilha TCP para remontar o fluxo de tráfego. Pode não ser ordens de grandeza, mas pode ajudar.

As conexões locais para o servidor usam, acredito, pipes em vez de conexões TCP e provavelmente não são afetadas por essa mudança.

    

Answer 2

Você pode tentar, mas duvido que ajude muito. O TDS como protocolo nunca foi projetado para alta produtividade. Se você quiser mover dados entre duas instâncias do servidor SQL, considere usar Service Broker Em vez disso, sua pilha de rede é muito mais orientada para a alta produtividade do que a do TDS. É por isso que o espelhamento escolhe a pilha de rede SSB para se comunicar com os servidores de espelhamento de espera. Além disso, a semântica de movimento de dados do SSB é muito melhor do que os servidores vinculados e, geralmente, é melhor do que os aplicativos personalizados do cliente.

    

Answer 3

Eu não posso comentar sobre tcp, frames, etc, mas eu só configurei o tamanho do pacote de rede do SQL Sever uma vez, para alguns aplicativos vil que ainda precisavam das ferramentas do cliente SQL 6.5.

É uma dessas configurações "não faça isso".