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

Question

Eu tenho E / S de CPU estável em torno de 50%, mas quando executo iostat 1 ele mostra pouca ou nenhuma atividade de disco.

O que causa a espera sem iops?

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

    

Answer 1

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

    

Answer 2

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

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

    

Answer 3

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

Se este for um ambiente Xen em que você pode obter acesso ao hipervisor, verifique o IOwait de fora para a imagem de disco (arquivo, rede, fatia LVM, qualquer que seja) usada para os dispositivos xvda e xvdb. Você também desejará verificar o sistema de E / S, em geral, para o hypervisor, já que outros dispositivos de disco podem estar monopolizando 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 para entrada quanto para saída da imagem da VM.

    

Answer 4

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

Editar

Eu vi que você está usando o xen, dê uma olhada nas interrupções atuais, você pode achar que o blkif está acima do normal.

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

    

Answer 5

sudo sysctl vm.block_dump=1

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

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

    

Answer 6

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

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

hdparm -f

no (s) disco (s) físico (s) subjacente (s). Possivelmente, o cache de disco não funciona com precisão. Isso irá liberar os dados armazenados no cache, e você pode monitorar constantemente o I / O, se está prestes a subir novamente após o flush. Se sim, será um problema de cache.

    

Answer 7

Com a média de carga, vi operações de rede bloqueadas (isto é, chamadas longas para um servidor de banco de dados externo) aumentarem. Eu não sei ao certo, mas eu estou supondo que o IO da rede pode fazer com que a CPU espere para subir? Alguém pode confirmar?

    

Answer 8

Podem ser dispositivos de loopback, eles próprios montados na rede.

    

Answer 9

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

SCP às vezes também parece levar a IO Wait, mas em muito menor extensão.

    

Answer 10

Isso pode ser qualquer coisa. Significa apenas que algo está esperando pelo final da operação de E / S. Você pode descobrir qual é o processo via ps, em seguida, anexar o gdb a ele e check-out backtrace para determinar qual chamada está travada (geralmente isso é algum material relacionado à rede ou disco desconectado de repente). Para informações fd, confira / proc.

    

Answer 11

Eu também experimentei um problema parecido antes que um disco em um RAID falhasse e alguns cabos SATA com curvas apertadas começassem a falhar.

O uso da CPU estava próximo de 0%, mas 1 ou mais CPUs em um sistema 4-core estavam gastando 100% de seu tempo no IOwait por longos períodos de tempo (encontrado via top multi-line cpu display) com muito baixa IOps e largura de banda (encontrada via iostat ), mas alta atividade de interrupção em rajadas. O uso interativo da linha de comando foi penoso durante qualquer acesso ao disco (ou seja, salvar automaticamente a partir da sessão emacs de alguém), mas tolerável quando os períodos de IOwait passavam (e presumivelmente as operações foram bem sucedidas após muitas tentativas).