Por que a VM do Linux no vSphere ESXi 5.5 mostraria uma latência de E / S de disco significativamente aumentada?

Estou perplexo e espero que outra pessoa reconheça os sintomas desse problema.

Hardware: novo Dell T110 II, Pentium G850 de 2,9 GHz de núcleo duplo, controlador SATA integrado, um novo disco rígido com cabo de 500 GB 7200 RPM dentro da caixa, outras unidades internas, mas ainda não montadas. Sem RAID. Software: nova máquina virtual CentOS 6.5 sob VMware ESXi 5.5.0 (build 1746018) + vSphere Client. RAM de 2,5 GB alocada. O disco é como o CentOS se ofereceu para configurá-lo, ou seja, como um volume dentro de um Grupo de Volume LVM, exceto pelo fato de eu ter deixado de ter um / home separado e simplesmente ter / e / boot. O CentOS está atualizado, o ESXi atualizado, as mais recentes ferramentas VMware instaladas na VM. Nenhum usuário no sistema, nenhum serviço em execução, nenhum arquivo no disco, mas a instalação do SO. Estou interagindo com a VM por meio do console virtual da VM no vSphere Client.

Antes de prosseguir, eu queria verificar se as coisas estavam configuradas de forma mais ou menos razoável. Executei o seguinte comando como root em um shell na VM:

for i in 1 2 3 4 5 6 7 8 9 10; do
  dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done

Ou seja, basta repetir o comando dd 10 vezes, o que resulta na impressão da taxa de transferência a cada vez. Os resultados são perturbadores. Começa bem:

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...

mas depois de 7-8 deles, ele imprime

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s

Se eu esperar um tempo significativo, digamos 30 a 45 minutos, e executá-lo novamente, ele volta a 105 MB / s e, após várias rodadas (às vezes algumas, às vezes 10 ou mais), cai para ~ 20- 25 MB / s novamente.

Com base na pesquisa preliminar de possíveis causas, em particular o VMware KB 2011861 , alterei o agendador de E / S do Linux para " noop" em vez do padrão. cat /sys/block/sda/queue/schedulermostra que está em vigor. No entanto, não vejo que isso tenha feito alguma diferença nesse comportamento.

Ao plotar a latência do disco na interface do vSphere, ele mostra períodos de alta latência do disco atingindo 1,2 a 1,5 segundos durante os tempos em que ddo baixo débito é relatado. (E sim, as coisas ficam sem resposta enquanto isso acontece.)

O que poderia estar causando isso?

Sinto-me confortável por não ter ocorrido uma falha no disco, porque eu também havia configurado outros dois discos como um volume adicional no mesmo sistema. No começo, pensei ter feito algo errado com esse volume, mas depois de comentar o volume em / etc / fstab e reiniciar e experimentar os testes em / como mostrado acima, ficou claro que o problema está em outro lugar. Provavelmente é um problema de configuração do ESXi, mas não tenho muita experiência com o ESXi. Provavelmente é algo estúpido, mas depois de tentar descobrir isso por muitas horas ao longo de vários dias, não consigo encontrar o problema, então espero que alguém possa me indicar a direção certa.

(PS: sim, eu sei que essa combinação de hardware não ganhará nenhum prêmio de velocidade como servidor e tenho motivos para usar esse hardware de baixo custo e executar uma única VM, mas acho que esse é o ponto mais importante para esta pergunta [a menos que na verdade, é um problema de hardware].)

ADENDO # 1 : Leitura outras respostas como este me fez tente adicionar oflag=directa dd. No entanto, não faz diferença no padrão de resultados: inicialmente os números são mais altos em muitas rodadas e depois caem para 20-25 MB / s. (Os números absolutos iniciais estão no intervalo de 50 MB / s.)

ADENDO # 2 : A adição sync ; echo 3 > /proc/sys/vm/drop_cachesao loop não faz diferença.

ADENDO Nº 3 : Para remover mais variáveis, agora corro de ddforma que o arquivo criado seja maior que a quantidade de RAM no sistema. O novo comando é dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Os números de taxa de transferência inicial com esta versão do comando são ~ 50 MB / s. Eles caem para 20-25 MB / s quando as coisas vão para o sul.

ADENDO # 4 : Aqui está o resultado da iostat -d -m -x 1execução em outra janela do terminal, enquanto o desempenho é "bom" e, novamente, quando é "ruim". (Enquanto isso acontece, estou correndo dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) Primeiro, quando as coisas estão "boas", isso mostra o seguinte:

Quando as coisas vão "ruins", iostat -d -m -x 1mostra o seguinte:

ADENDO Nº 5 : Por sugestão do @ewwhite, tentei usar tunedcom perfis diferentes e também tentei iozone. Neste adendo, relato os resultados de experimentar se tunedperfis diferentes tiveram algum efeito no ddcomportamento descrito acima. Eu tentei mudar o perfil para virtual-guest, latency-performancee throughput-performance, mantendo tudo o resto igual, reiniciando após cada alteração, e então cada tempo de execução dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Isso não afetou o comportamento: assim como antes, as coisas começam bem e muitas execuções repetidas ddmostram o mesmo desempenho, mas, em algum momento após 10 a 40 execuções, o desempenho cai pela metade. Em seguida, eu usei iozone. Esses resultados são mais extensos, por isso estou colocando-os no anexo 6 ​​abaixo.

ADENDO Nº 6 : Por sugestão do @ewwhite, instalei e usei iozonepara testar o desempenho. Executei-o em diferentes tunedperfis e usei um parâmetro de tamanho máximo de arquivo (4G) muito grande iozone. (A VM tem 2,5 GB de RAM alocada e o host tem 4 GB no total.) Essas execuções de teste levaram algum tempo. FWIW, os arquivos de dados brutos estão disponíveis nos links abaixo. Em todos os casos, o comando usado para produzir os arquivos foi iozone -g 4G -Rab filename.

• Perfil latency-performance:
  • resultados brutos: http://cl.ly/0o043W442W2r
  • Planilha do Excel (versão OSX) com gráficos: http://cl.ly/2M3r0U2z3b22
• Perfil enterprise-storage:
  • resultados brutos: http://cl.ly/333U002p2R1n
  • Planilha do Excel (versão OSX) com gráficos: http://cl.ly/3j0T2B1l0P46

O seguinte é o meu resumo.

Em alguns casos, reinicializei após uma execução anterior, em outros casos, não e simplesmente executei iozonenovamente após alterar o perfil com tuned. Isso não pareceu fazer uma diferença óbvia nos resultados gerais.

tunedPerfis diferentes não pareciam (para meus olhos reconhecidamente inexperientes) afetar o amplo comportamento relatado por iozone, embora os perfis afetassem certos detalhes. Primeiro, sem surpresa, alguns perfis alteraram o limite em que o desempenho caiu para gravar arquivos muito grandes: plotando os iozoneresultados, você pode ver um penhasco puro a 0,5 GB para o perfil, latency-performancemas essa queda se manifesta em 1 GB no perfilenterprise-storage. Segundo, embora todos os perfis exibam uma variabilidade estranha para combinações de tamanhos de arquivos pequenos e de registros pequenos, o padrão preciso de variabilidade diferia entre os perfis. Em outras palavras, nas plotagens mostradas abaixo, o padrão irregular no lado esquerdo existe para todos os perfis, mas os locais dos poços e suas profundidades são diferentes nos diferentes perfis. (No entanto, não repeti execuções dos mesmos perfis para ver se o padrão de variabilidade muda visivelmente entre execuções do iozonemesmo perfil, portanto, é possível que o que pareça diferenças entre perfis seja realmente apenas uma variabilidade aleatória.)

A seguir, são apresentados gráficos de superfície dos diferentes iozonetestes para o tunedperfil de latency-performance. As descrições dos testes são copiadas da documentação para iozone.

Teste de leitura: este teste mede o desempenho da leitura de um arquivo existente.

Teste de gravação: este teste mede o desempenho da gravação de um novo arquivo.

Leitura aleatória: este teste mede o desempenho da leitura de um arquivo com acessos sendo feitos em locais aleatórios no arquivo.

Gravação aleatória: esse teste mede o desempenho da gravação de um arquivo com acessos sendo feitos em locais aleatórios no arquivo.

Fread: Este teste mede o desempenho da leitura de um arquivo usando a função de biblioteca fread (). Esta é uma rotina de biblioteca que executa operações de leitura em buffer e bloqueadas. O buffer está dentro do espaço de endereço do usuário. Se um aplicativo ler em transferências de tamanho muito pequeno, a funcionalidade de E / S em buffer e bloqueada de fread () poderá melhorar o desempenho do aplicativo, reduzindo o número de chamadas reais do sistema operacional e aumentando o tamanho das transferências quando o sistema operacional chamadas são feitas.

Escrita: Este teste mede o desempenho da gravação de um arquivo usando a função de biblioteca fwrite (). Esta é uma rotina de biblioteca que executa operações de gravação em buffer. O buffer está dentro do espaço de endereço do usuário. Se um aplicativo escrever em transferências de tamanho muito pequeno, a funcionalidade de E / S em buffer e bloqueada de fwrite () poderá melhorar o desempenho do aplicativo, reduzindo o número de chamadas reais do sistema operacional e aumentando o tamanho das transferências quando o sistema operacional chamadas são feitas. Esse teste está gravando um novo arquivo, portanto, novamente a sobrecarga dos metadados é incluída na medição.

Por fim, durante o período em que iozoneestava fazendo o seu trabalho, também examinei os gráficos de desempenho da VM na interface do cliente do vSphere 5. Alternei entre as plotagens em tempo real do disco virtual e o armazenamento de dados. Os parâmetros de plotagem disponíveis para o armazenamento de dados eram maiores do que para o disco virtual, e os gráficos de desempenho do armazenamento de dados pareciam refletir o que os gráficos de disco e disco virtual estavam fazendo; portanto, aqui incluo apenas uma captura instantânea do gráfico do armazenamento de dados obtido após a iozoneconclusão (sob tunedperfil latency-performance) As cores são um pouco difíceis de ler, mas o que talvez seja mais notável são os acentuados picos verticais na leituralatência (por exemplo, às 4:25, depois novamente um pouco depois das 4:30 e novamente entre 4: 50-4: 55). Nota: o gráfico é ilegível quando incorporado aqui, então também o enviei para http://cl.ly/image/0w2m1z2T1z2b

Devo admitir que não sei o que fazer com tudo isso. Eu especialmente não entendo os perfis estranhos de buracos nas regiões de pequeno registro / tamanho de arquivo pequeno das iozoneparcelas.

Você pode fornecer o número exato da versão do ESXi? Por favor, tente os testes novamente com uma ferramenta de análise de desempenho de disco criada especificamente para fins como fio ou iozone para obter uma linha de base real. Usar ddnão é realmente produtivo para isso.

Em geral, o planejador de E / S padrão no EL6 não é tão bom. Você deve mudar para o prazo final ou elevadores de E / S noop ou, melhor ainda, instalar a estrutura ajustada .

Tente: yum install tuned tuned-utilse tuned-adm profile virtual-guest, em seguida, teste novamente.

Encontrei o mesmo problema e notei um desempenho muito lento da unidade nas máquinas virtuais. Estou usando o ESXi 5.5 em um Seagate ST33000650NS.

Seguindo este artigo do kb, mudei Disk.DiskMaxIOSizepara o tamanho do bloco dos meus discos. No meu caso 4096.

A observação da VMware sobre isso é muito legal, pois você pode testá-lo.

Nota: Você pode fazer essa alteração sem reiniciar o host ESX / ESXi ou sem colocar o host ESX / ESXi no modo de manutenção.

Eu sei que essa pergunta é muito antiga, mas mhucka colocou tanta energia e informação em seu post que eu tive que responder.

Editar # 1: Depois de usar 4096 por um dia, voltei ao valor antigo 32767. Testar o IO e tudo ainda parece estável. Meu palpite é que a execução de um ESXi em um HDD normal com o Disk.DiskMaxIOSizeset to 32767funcionará bem por algumas horas ou talvez dias. Talvez seja necessário um pouco de carga das VMs para reduzir gradualmente o desempenho.

Eu tento investigar e voltar mais tarde ...

Tente descobrir em que local da pilha de armazenamento as altas latências são causadas:

fonte: Solucionando problemas de desempenho de armazenamento no vSphere - Parte 1 - Noções básicas