Provavelmente, a maneira mais fácil de testá-lo é usar o SQLIO. Eu tenho um tutorial aqui:
Você pode testá-lo antes & depois de ver se os jumbo frames ajudaram ou não.
Digamos que temos uma caixa do SQL Server 2000 que hospeda nosso mecanismo de banco de dados principal.
Adicionamos uma SAN iSCSI e agora esse servidor tem uma placa conectada à rede comum e uma placa conectada à rede iSCSI.
Os dados são solicitados por meio de outro servidor, que é o nosso servidor de aplicativos e não está na rede iSCSI.
Ativamos Jumbo Packets para 9000 na conexão iSCSI no servidor de dados (bem como nos outros itens da rede iSCSI).
Depois de ler um artigo por Jonathan Kehayias Estou me perguntando se o que fizemos está certo.
Qual é a melhor maneira de testar isso no meu sistema OLTP? O SO é o Windows Server 2003 R2 Enterprise x64 SP2 e o SQL Server é o Enterprise 2000 x86.
Provavelmente, a maneira mais fácil de testá-lo é usar o SQLIO. Eu tenho um tutorial aqui:
Você pode testá-lo antes & depois de ver se os jumbo frames ajudaram ou não.
O conselho no artigo ao qual você está vinculado é muito bom e explica as razões pelas quais os Jumbo frames não são necessariamente uma boa ideia em ambientes LAN de uso geral, mas ele não discute realmente a natureza do próprio tráfego de rede iSCSI e geralmente se beneficia de quadros Jumbo, pois o tráfego de E / S do disco estará em blocos relativamente grandes - 8kb se você não tiver modificado. Alguns especialistas em SQL podem querer me corrigir, mas acho que todo o IO do banco de dados estará em blocos de 8kb. Se o tamanho do bloco de leitura / gravação for 8k, um único IO poderá caber em um único quadro Jumbo (a sobrecarga de protocolo é relativamente baixa - < 100 bytes geralmente) em vez de ser dividido em seis tamanhos padrão.
Você provavelmente não verá nenhuma mudança significante de transferência (talvez alguns%), mas o que eu esperaria ver seria uma carga de CPU e taxa de interrupção significativamente menores do driver da interface de rede, já que suas NICs geralmente estarão lidando apenas com 1 / 6 o número de pacotes para transportar a mesma quantidade de dados. Isso pode não ser um grande negócio para você, mas se você tiver várias NICs transportando tráfego iSCSI, isso pode adicionar uma grande quantidade de recursos da CPU ou um servidor ocupado. Se você tiver NICs inteligentes com offload de iSCSI \ TCP, os benefícios serão obviamente menores, mas no geral o tamanho de quadro aumentado ainda facilita para tudo na malha de rede iSCSI, por isso ainda seria recomendado.
Dito isso, eu ecoaria a recomendação de Brent Ozar de que você realizasse alguns testes de desempenho, se fosse possível.
Eu ficaria surpreso se fosse outra coisa senão uma ajuda. Concedido, eu sou um SA Unix, não um cara DBA / Networking / Windows, mas espero que ele não faça nada além de bom (supondo que seja suportado de ponta a ponta, é claro).
Eu esperaria que o banco de dados estivesse lendo e escrevendo pelo menos uma página por vez, geralmente uma página DB tem o mesmo tamanho de uma página do sistema operacional (a maioria dos sistemas RISC tinha 4K para 32 bits e 8K para 64 pouco, mas eu suspeito que ainda é um 4K para sistemas 6464 AMD64). Claro, teoricamente, você poderia ler e escrever blocos de discos individuais (512 bytes), mas aposto que não. Portanto, com 4K vs 1.5K (ethernet normal), você pode atender a maioria das solicitações com 1/3 do número de pacotes, o que deve ser uma vitória, possivelmente até mesmo notável.
O artigo é completamente irrelevante para sua preocupação. Ele fala sobre o tráfego de aplicativos que seu SQL Server vê. Por outro lado, você tem uma dúvida sobre conectividade de armazenamento - tráfego que o iniciador iSCSI do seu servidor vê.
Então, primeiro, esqueça o artigo.
Em segundo lugar, ainda estou para ver as práticas recomendadas, o white paper ou o manual de um fornecedor de armazenamento que NÃO recomendaria "habilitar quadros gigantes".
A aplicação não importa. Plataforma não importa. O iSCSI gosta de quadros jumbo, ponto final.
Tags 64-bit sql-server jumboframes