De acordo com a página man:
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be
repeated 2-3 times on an otherwise inactive system (no other
active processes) with at least a couple of megabytes of free
memory.
Então, sim, outros processos podem interferir nesses resultados.
Are there any other areas or tests I can run?
Uma maneira de ver se outros processos estão utilizando o (s) disco (s) é fazer o download de sysstat da página principal aqui .
O Sysstat já está disponível no repositório, mas infelizmente não inclui o comando pidstat que é necessário para verificar isso.
Os kernels EL5 backportaram a contagem de disco para o kernel desde o EL5.4 sem fornecer uma interface para utilizá-lo, mas o pidstat funcionará assim que você fizer isso.
Em seguida, execute o comando pidstat -d para gerar métricas úteis para E / S de disco, especialmente o que outros processos estão fazendo com o disco. Você também pode usar pidstat -d <interval> <count> para obter uma métrica de contenção mais em tempo real do disco que está sendo usado.
Would any sort of VM/OS corruption cause this type of behavior?
A corrupção do SO é bastante improvável (chamadas do sistema sendo parafusadas de alguma forma, eu acho). O hdparm não utiliza o sistema de arquivos para fazer seus testes, o que elimina qualquer desaceleração dessa área, incluindo problemas de desregulação. Se você usa o LVM, existe o risco de você estar lendo extensões que estão fragmentadas. Seus exemplos não indicam isso no entanto.
Corrupção da VM, bem, qualquer coisa que eu possa imaginar, e isso se resume a uma série de fatores que eu posso pensar de improviso, mas provavelmente incluiria mais:
- Em qual formato de imagem o disco está.
- Como esses dados são alocados para o mecanismo de armazenamento subjacente (é um volume lógico com extensões em si?)
- Se houver uma reconstrução de ataque ou alguma outra manutenção de nível de bloco dentro do controlador de disco. I.E se o controlador for realmente uma SAN fazendo alguma forma de rebalanceamento de raids.
- Falha de disco em um ataque forçando cálculos de paridade.
- Se os dados estão sendo lidos na realidade por um cache "rápido" como o FusionIO, o cache de dados presente em SANs ou cartões de ataque com bateria.
- Se a mídia subjacente está dividindo seu armazenamento de alguma forma.
- Contenção de disco pelo hipervisor que faz com que suas solicitações de I / O sejam enfileiradas por mais tempo.
- Contenção de disco pela SAN que faz com que as solicitações de E / S sejam enfileiradas por mais tempo (é muito comum as VMs residirem no armazenamento compartilhado).
- Volumes thin provisionados representam um alto risco de fragmentação. Como isso afeta seu teste é completamente determinado por quantos blocos você é alocado para uma extensão thinly provisioned. Por exemplo, no provisionamento thin LVM no linux, o tamanho da extensão é, por padrão, 32M, portanto, passar um marcador de 32M em seu disco pode impor uma busca extra que atrapalhe seus horários.
Would rebuilding/replacing the VM help?
Pot sorte, eu acho que é melhor ou pior. Veja os fatores ambientais acima que podem ajudar / atrapalhar.
No final do dia, se você estiver usando software de gerenciamento de volume ou thin provisioning em qualquer ponto do fluxo de dados sendo gravado na mídia (no host, no nível da VM, no nível da controladora / SAN) você pode ter nenhuma expectativa confiável de que a leitura sequencial que você está fazendo é realmente seqüencial ou que a mídia na qual você está gravando é consistente (se for um disco ou dados rápidos movidos para um disco lento). / p>
A virtualização é tão poderosa porque adiciona uma camada de abstração lógica a um host. Mas também pode ser potencialmente horrível realizar qualquer grau confiável de gerenciamento de capacidade sobre eles por causa dessa camada de abstração.