Ser um administrador de banco de dados pode ser muito desafiador quando você precisa solucionar problemas de desempenho. O servidor de banco de dados é apenas um componente do ecossistema de aplicativos e rotineiramente é considerado o problema de desempenho. O SQL Server é uma daquelas caixas pretas que muitos não entendem, assim como a SAN e a rede. Os DBAs de produção que monitoram seus servidores podem identificar rapidamente se o SQL Server está funcionando fora de sua linha de base normal, mas há duas áreas principais sobre as quais temos pouca visibilidade:a SAN e a rede. Os DBAs precisam trabalhar regularmente com outros engenheiros quando se trata de solucionar problemas de desempenho que não estão diretamente relacionados ao SQL Server. Podemos acompanhar facilmente o desempenho do disco monitorando sys.dm_io_virtual_file_stats , sobre o qual escrevi em Monitoring Read/Write Latency; no entanto, rastrear problemas de desempenho de rede no SQL Server não é tão fácil.

O baixo desempenho da rede pode ser um assassino silencioso para o desempenho do aplicativo e minha experiência pessoal mostrou que esse é o caso em muitas ocasiões. Muitas vezes, um aplicativo começava a ter problemas de desempenho e o engenheiro de aplicativos dizia que o servidor de aplicativos parece bom e começa a apontar o dedo para o banco de dados. Eu recebia uma ligação para examinar o servidor de banco de dados e todas as indicações mostravam que o servidor de banco de dados estava em boas condições (e é aqui que o monitoramento dos principais indicadores de desempenho e uma linha de base ajudam!). Como as equipes de aplicativos e banco de dados estavam dizendo que tudo estava bem, pedíamos à equipe de rede para verificar as coisas. A equipe da rede examinaria algumas coisas e daria tudo claro do seu lado também. Cada equipe solucionando problemas e revisando seus respectivos sistemas levava tempo, enquanto o desempenho do aplicativo ainda sofria. O problema seria escalado até que todas as equipes fossem solicitadas a ingressar em uma ponte de conferência para solucionar o problema em conjunto. Eventualmente, alguém iniciaria um teste de rede mais profundo e determinaria que tínhamos uma saturação de porta, roteamento ou algum outro problema de rede complexo. Alguns cliques ou a alteração de alguma coisa acabariam por resolver a lentidão do aplicativo.

O problema de rede mais significativo que encontrei com clientes geralmente envolve largura de banda ao realizar backups. Muitas organizações maiores estão migrando para a rede de 10 Gb para infraestrutura principal, no entanto, ao trabalhar com rede física e virtual, é fácil configurar incorretamente uma configuração ou porta e reduzi-la para 1 Gb. Para tráfego de rede de aplicativo regular, você pode não notar a degradação no desempenho, no entanto, assim que você começar a tentar copiar 100s de GB de dados para backups, esse 1Gb ficará saturado e seus trabalhos de backup e restauração sofrerão.

Para DBAs, pode ser um desafio fazer com que outras pessoas analisem tão profundamente os problemas que eles acham que não são seu problema, porque os indicadores iniciais não revelam o problema. Ser capaz de se armar com dados antes de entrar em contato com outras equipes ajudará a envolvê-las. Ao usar o iPerf para fazer um teste inicial de largura de banda, você pode determinar rapidamente se está obtendo as velocidades de rede que deveria. Por exemplo, se você estiver utilizando uma rede de 10 Gb entre o servidor de aplicativos e o servidor de banco de dados e executar um teste e estiver obtendo apenas 1 Gb, saberá que algo não está certo. Se você puder documentar essa descoberta, poderá pedir com confiança aos seus engenheiros de rede que analisem um problema de largura de banda.

Como você começa a usar o iPerf? Primeiro você precisa baixar a ferramenta de iPerf.fr. Como estou trabalhando no Windows Server 2012, baixei os binários do Windows para minha máquina. Depois de baixar e descompactar o pacote, você precisará executar o programa a partir de uma linha de comando. Baixei o iPerf 3.0.11 que já está no mercado há quase um ano. Certifique-se de ler a documentação deste utilitário. Como esta é uma ferramenta de linha de comando, existem dezenas de opções que você pode usar. No exemplo abaixo, usarei apenas alguns deles, porém, dependendo da sua situação, você pode precisar usar outras opções, como especificar a porta ou aumentar o tamanho do pacote. Observe que os comandos de opção diferenciam maiúsculas de minúsculas.

Para usar o iPerf, você precisa usar pelo menos dois servidores para testar a largura de banda. Depois de copiar os binários para os dois servidores, você deve primeiro iniciar o ouvinte iPerf em um dos servidores. Para isso vou executar o seguinte comando:
iperf3 -s
Este comando executa o iPerf em modo servidor e só permitirá uma conexão por vez.

No segundo servidor, você precisará iniciar o iPerf usando várias opções do cliente. Primeiro vamos especificar -c para especificar o modo cliente. Também usaremos -t para especificar o tempo de execução de cada teste e -P para especificar o número de conexões simultâneas a serem feitas. Queremos especificar várias conexões para que possamos colocar uma pressão adequada na rede. Para este teste, vou executar o seguinte comando:
iperf3 -c (nome do servidor ou endereço IP do primeiro servidor) -t 30 -P 10
O comando acima iniciará um teste de transmissão de 30 segundos com 10 conexões simultâneas.

Eu executei este teste em duas máquinas virtuais no meu Dell M6800, então não havia uma rede física para essas VMs passarem.

Do servidor 2 conectando ao servidor 1, obtive 7,57 GBytes transferidos com uma largura de banda de 2,17 Gbits/s. Nada mal para algumas VMs em um laptop.

Estatísticas de rede/saída iPerf:Servidor 2 conectando-se ao Servidor 1

Do servidor 1 conectando ao servidor 2, obtive 6,98 GBytes transferidos com uma largura de banda de 2,00 Gbits/s. Como você pode ver, há uma pequena diferença nos números, mas ainda relativamente próximos. Se esses números fossem drasticamente diferentes, eu precisaria investigar a causa.

Estatísticas de rede/saída iPerf:Servidor 1 conectando-se ao Servidor 2

É importante executar esses testes antes de entrar em produção e ter o hábito de repetir regularmente esses testes em seus servidores de produção. Você precisa saber o que é normal, se você não está monitorando, então você não pode medir. Se você souber que atualizações de firmware estão sendo executadas em seus servidores, no host virtual ou em qualquer equipamento de rede principal, um teste iPerf antes e depois das alterações pode alertá-lo rapidamente para identificar quaisquer efeitos colaterais negativos.

Também é importante realizar esse teste em qualquer servidor que faça interface diretamente com o servidor de banco de dados e em qualquer servidor com o qual o servidor de banco de dados faça interface direta, como dispositivos de backup de rede. O IPerf funciona tanto no Windows quanto no Linux, facilitando o teste entre os dois sistemas operacionais.

Para DBAs, a rede não precisa mais ser uma caixa preta sobre a qual você não sabe nada. O uso do iPerf pode alertá-lo sobre quaisquer problemas de largura de banda com a rede entre o servidor de banco de dados e qualquer outro servidor. Não há razão para confiar apenas no PING e no TRACERT para solução de problemas de rede limitada. Baixe o iPerf e comece a documentar sua largura de banda de rede.