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.
iostate mostrou ~ 90% de utilização antes e depois. Mas não sou especialista em julgar essas coisas - talvez a saturação esteja acontecendo em algum lugar. Estou atualizando minha pergunta para mostrar a iostatsaída, caso seja útil.
