Você consegue detectar desalinhamento de partição de uma VM?

Question

Primeiro de tudo, a história por trás -

De repente (literalmente durante a noite), uma instância começa a lançar alertas de utilização da CPU. Esta é uma VM um pouco humilde (1 vCPU, 2 GB de RAM), mas tudo o que ela faz é servir muito NFS e pesquisar Cactos e servir para um punhado de sistemas. Essa VM é hospedada em um provedor de IaaS no vSphere 4.xe está no kit corporativo (HP / NetApp SAN, etc.).

A última vez que mudei alguma coisa neste sistema foi quase 4 semanas atrás. Observando as métricas, um dos agentes / processos do provedor usado pela McAfee (cma) consumiu mais RAM do que o habitual até um trabalho cron Eu reiniciei o serviço no fim de semana anterior (o trabalho cron está lá porque estou convencido de que esse agente tem um vazamento de memória). De qualquer forma, o problema é que eu não posso mais executar o Cacti (httpd / mysql / php cron job que executa poller.php) neste sistema - a carga irá subir mais de 10 e o iowait é realmente alto (~ 90%). Eu tentei o seguinte:

• execute o Cacti com o serviço da McAfee interrompido
• sistematicamente atualizado php *, httpd / mod_ssl, mysql-server, após cada tentativa de executar o Cacti
• atualização do yum para todos os pacotes mais recentes, agora é RHEL 5.8 (x86_64)

A atualização do yum (todos) colocou o sistema em uma carga de 6 e levou horas.

Perguntei ao provedor de hospedagem se havia algo errado com a camada de armazenamento, mas eles disseram que não havia. Mas isso simplesmente não computa. Isso me fez pensar se talvez poderia haver um problema com o desalinhamento da partição, uma vez que li que pode causar o tipo de sintoma que parece estar ocorrendo. Agora, o provedor teria criado essas partições do VMFS no cliente do vSphere / vCenter, o que eu entendo garante que haja alinhamento. Mas pode sair do alinhamento ao longo do tempo? Em caso afirmativo, existe alguma maneira de uma VM / Convidado que você possa detectar isso? O utilitário mbrscan (NetApp) parece detectar, mas precisa ser executado a partir do console ESX do host.

Obrigado!

Edit: saída do sfdisk com o uS adicionado:

    [root@nfs1 ~]# sfdisk -luS /dev/sda

Disk /dev/sda: 13054 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sda1   *        63    208844     208782  83  Linux
/dev/sda2        208845 164055779  163846935  83  Linux
/dev/sda3     164055780 209712509   45656730  8e  Linux LVM
/dev/sda4             0         -          0   0  Empty

Atualização:

Uma reinicialização desta instância resolveu completamente os problemas de desempenho. Uma análise mais aprofundada pelo Provedor de Hospedagem indicou que há algum desalinhamento, mas na opinião deles não resultaria em sintomas experimentados. Eles dizem, por exemplo, que o desalinhamento em VMs do Windows é maior. Neste ponto, vamos esperar e ver se isso acontece novamente e, se for o caso, alterar o deslocamento do setor.

    

Answer 1

A única maneira de ver os problemas de alinhamento é medir o registro mestre de inicialização. Se você puder fazer isso com sua VM, poderá ver se está desalinhado.

Dito isso, os problemas de alinhamento aumentam o número de pedidos de veiculação que você faz para o armazenamento, mas deve haver alguma limitação para evitar que você faça esse aumento no número de pedidos de veiculação. O Netapp é particularmente atingido por isso, porque eles começam a limitar o desempenho assim que o número de "gravações parciais" que precisam de atenção extra pelo back-end atinge um certo nível. Outros sistemas apenas tratam cada IO da mesma maneira que o último, então não tenha aquele pico massivo de latência de armazenamento que o Netapp recebe.

    

Answer 2

Você deve ser capaz de descobrir o alinhamento do convidado com o sfdisk no Linux. Basta olhar para os setores iniciais de suas partições. Mas , isso só lhe dirá metade da história, já que seu provedor pode / deve ser responsável pelo alinhamento padrão do sistema operacional na camada de armazenamento.

Assim, mesmo que pareça desalinhado em algo como 63 setores, o armazenamento pode ter um deslocamento para o LUN ou para o armazenamento de dados para corrigi-lo em um limite alinhado. Mas pelo menos você pode levar seu novo conhecimento ao seu provedor e fazer com que ele confirme.

Atualização (para novos resultados do sfdisk): Nenhuma de suas partições está alinhada nos mesmos limites de bloco de 4KB ou 8KB, portanto, é bem provável que você esteja tendo algum problema de desalinhamento. Você precisa perguntar ao seu provedor qual alinhamento de bloco o armazenamento usa (por exemplo, 4KB) e qual correção de alinhamento ele usa, se houver. Se eles não tiverem nenhuma correção de alinhamento, você quer que todas as suas partições iniciem em uma contagem setorialmente divisível por 8 ou 16. Enquanto você está nisso, um deslocamento inicial igual a 1MB (uniformemente divisível por 2048) permite mudanças no tamanho do bloco de armazenamento no futuro.