O que cria a espera de E / S da CPU, mas nenhuma operação de disco?


12

Tenho E / S de CPU em espera em torno de 50%, mas quando executo, iostat 1ela mostra pouca ou nenhuma atividade em disco.

O que causa a espera sem IOP?

NOTA: Não há sistemas de arquivos NFS ou FUSE aqui, mas ele está usando a virtualização Xen.

insira a descrição da imagem aqui


Que distro? Qual versão?
ZaMoose

2
Além disso: esta é uma máquina de hiper viseira Xen ou uma VM com os iowaits?
ZaMoose

Does iotopmostrar-lhe alguma coisa?
Janne Pikkarainen

Respostas:


7

O NFS pode fazer isso e não me surpreenderia se outros sistemas de arquivos de rede (e até dispositivos baseados em FUSE) tivessem efeitos semelhantes.


Obrigado, mas neste caso não há NFS nem FUSE. Vou acrescentar isso à pergunta também.
Jason Cohen

6

Existe alguma chance de outras VMs no servidor estarem debulhando o disco?

Eu sei com virtualização que você pode obter alguns resultados estranhos se o nó do host estiver sobrecarregado.


Verdadeiro, mas isso deve estar em roubar% em vez de io% certo? Ou pode atravessar por lá também?
Jason Cohen

3
O roubo ocorre quando há menos capacidade da CPU disponível do que o solicitado pelas VMs. Se o disco físico estiver sobrecarregado, seus processos passarão muito tempo em Iowait, aguardando sua vez no disco, mesmo que não estejam atingindo muito o disco.
achou

Sim isso. Veja outra pergunta com a mesma resposta em serverfault.com/a/209031/57468
mattdm

3

Se este for o ambiente Amazon EC2 Xen usando armazenamento baseado em instância, peça à Amazon para verificar a integridade do host que contém esta imagem.

Se esse é um ambiente Xen ao qual você pode obter acesso ao hypervisor, verifique o IOwait from from fora para a imagem de disco (arquivo, rede, fatia LVM, qualquer que seja) usada para os dispositivos xvda e xvdb. Você também deseja verificar o sistema de E / S, em geral, para o hipervisor, pois outros dispositivos de disco podem monopolizar os recursos do sistema.

iostat -txk 5

geralmente é uma boa ferramenta de diagnóstico inicial. São necessários resumos de 5 segundos de E / S para TODOS os dispositivos disponíveis e, portanto, é útil tanto na entrada quanto na saída da imagem da VM.


2

Verifique seus descritores / inodes de arquivos disponíveis. Quando você atinge o limite, eles trocam e imitam iowait

Editar

Vi que você está usando o xen, dê uma olhada nas suas interrupções atuais, você pode achar que o blkif está mais alto do que o normal.

Um pouco tarde agora, mas instale o munin e isso realmente ajudará na depuração futura.


1
sudo sysctl vm.block_dump=1

Em seguida, verifique o dmesg para ver o que está executando a leitura / gravação de bloco ou a sujeira de inodes.

Verifique também o limite de nofile em limits.conf, um processo pode estar solicitando mais arquivos do que é permitido abrir.


1

AVISO: O HDPARM É PERIGOSO, LEIA SEMPRE O COMANDO QUE VOCÊ VAI USAR!

Se nenhuma outra máquina virtual estiver sobrecarregando o (s) disco (s) rígido (s), faça

hdparm -f

no (s) disco (s) físico (s) subjacente (s). Possivelmente, o cache do disco não funciona com precisão. Isso liberará os dados armazenados no cache e você poderá monitorar constantemente a E / S, se está prestes a aumentar novamente após a liberação. Se sim, será um problema de cache.


0

Com a carga média, vi operações de rede bloqueadas (ou seja, chamadas longas para um servidor de banco de dados externo) aumentar. Não sei ao certo, mas acho que o IO da rede pode fazer com que a espera da CPU suba? Alguém pode confirmar?


1
Na maioria das máquinas modernas, não. A maioria, se não todos os sistemas recentes, possuem NICs compatíveis com DMA para evitar exatamente esse tipo de situação.
ZaMoose


0

Nas minhas máquinas, o NFS é o maior "produtor" de IO-WAIT. Eu tenho um SSD no meu laptop que é rápido como o inferno, então "IO real" não é o problema. No entanto, às vezes tenho muita espera de E / S devido aos meus compartilhamentos nfs montados.

Às vezes, o SCP também parece levar ao IO Wait, mas em uma extensão muito menor.


0

Isso pode ser qualquer coisa. Significa apenas que algo está aguardando o fim da operação de E / S. Você pode descobrir qual é o processo via ps, depois anexar o gdb e verificar o backtrace para determinar qual chamada está travada (geralmente são coisas relacionadas à rede ou disco subitamente desconectado). Para informações fd, consulte / proc.


0

Eu também experimentei um problema semelhante logo antes de um disco em um RAID falhar e alguns cabos SATA com curvas apertadas começarem a falhar.

O uso da CPU era próximo de 0%, mas 1 ou mais CPUs em um sistema de 4 núcleos gastavam 100% do tempo no IOwait por longos períodos de tempo (encontrados por meio de topuma tela cpu de várias linhas) com IOps e largura de banda muito baixas (encontrado via iostat), mas com alta atividade de interrupção. O uso interativo da linha de comando foi doloroso durante qualquer acesso ao disco (ou seja, salvamento automático da emacssessão de alguém ), mas tolerável quando os períodos de IOwait passaram (e, presumivelmente, as operações foram bem-sucedidas após várias tentativas).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.