Depurando a latência de E / S do Linux

Question

Estou tendo alguns problemas de E / S em alguns sistemas Linux que administro. Eles manifestam que os processos geralmente bloqueiam por até alguns segundos em syscalls simples como open (), unlink () ou close () em arquivos (o que é um problema porque alguns dos programas envolvidos precisam de baixa latência de E / S para operar devidamente). É verdade que os sistemas em questão experimentam alguma carga moderada de E / S, mas dificilmente posso pensar que isso seria suficiente para justificar esses enormes tempos de latência. Às vezes, as chamadas podem levar mais de 15 segundos para serem concluídas (embora, com mais frequência, elas demorem 1 ou 2 ou 3 segundos).

Minha pergunta é: como posso descobrir por que isso acontece? O que eu gostaria é de alguma ferramenta que poderia me dizer em que os processos em questão estão bloqueados no kernel, e por que aquilo em que eles dormem está ocupado, o que está acontecendo com ele e essas coisas. Existe tal ferramenta, ou existe alguma outra maneira de tentar depurar o que acontece?

Alternativamente, é claro, se você tem alguma pista sobre o que realmente está acontecendo, como isso pode ser evitado?

Para o registro, o sistema de arquivos que eu uso é o XFS.

    

Answer 1

Agora, no devido tempo, consegui resolver isso sozinho, para que eu possa, pelo menos, fazer o mesmo para a posteridade.

Infelizmente, perdi o problema original em uma atualização do kernel, mas ganhei um novo, ainda pior no desempenho, e tão difícil de rastrear. As técnicas que encontrei foram as seguintes:

Primeiro de tudo, blktrace / blkparse é uma ferramenta que achei bastante útil. Ele permite o rastreamento do progresso de solicitações individuais de E / S com muitos detalhes úteis, como o processo que enviou a solicitação. É útil colocar a saída em tmpfs , para que a manipulação do armazenamento do rastreio não comece a se rastrear.

Isso ajudou apenas até agora, então eu compilei um kernel com mais funcionalidades de depuração. Em particular, achei ftrace bastante útil, pois permitiu-me traçar o desempenho ruim processo dentro do espaço do kernel, para ver o que ele fez e onde bloqueou. A compilação de um kernel de depuração também fornece WCHAN de saída para ps , o que pode funcionar como uma maneira mais fácil de ver o que um processo está fazendo dentro do kernel, pelo menos em casos mais simples.

Eu também esperava que o LatencyTop fosse útil, mas eu achei muito bugs, e também que ele só exibia motivos de latência que eram muito "alto nível" para ser realmente útil, infelizmente.

Além disso, achei mais útil que iostat simplesmente visualizar o conteúdo de /sys/block/$DEVICE/stat em intervalos muito próximos, simplesmente assim:

while :; do cat /sys/block/sda/stat; sleep .1; done

Consulte Documentation/iostats.txt na árvore de origem do kernel para o formato do arquivo stat . Vê-lo a intervalos curtos permitiu-me ver a hora e o tamanho exacto das explosões de E / S e de tais coisas.

No final, descobri que o problema que tive após a atualização do kernel foi causado por páginas estáveis , um recurso introduzido no Linux 3.0, fazendo com que, no meu caso, o Berkeley DB parasse por longos períodos ao sujar as páginas em seus arquivos de região do mmap. Embora pareça possível consertar esse recurso, e também que os problemas que ele causa possam ser corrigidos no Linux 3.9, eu resolvi o pior problema que tive por agora por corrigindo o Berkeley DB para permitir que eu coloque seus arquivos de região em um diretório diferente (no meu caso /dev/shm ), permitindo-me evitar o problema completamente.

    

Answer 2

De acordo com minha experiência, a ferramenta estatística mais simples e mais detalhada que você pode instalar para rastrear problemas misteriosos de desempenho do sistema é link aka. sar

com certeza você também quer ver a saída do comando iostat, especialmente quanto seu% iowait deve estar abaixo de 5-10% sob carga normal do sistema (abaixo de 1.0).

veja a saída do ps se na coluna STAT aparecer D status que significa que esses processos estão bloqueados e aguardando o IO, muito provavelmente um problema de hardware com o controlador ou o disco, verifique as estatísticas SMART, bem como dmesg e syslog para pistas

verifique o log do sar e identifique os horários de pico, se isso acontecer, e tente combinar o tempo com tarefas agendadas intensivas em disco, por exemplo, backups pela rede

você pode comparar seu desempenho de disco com o bonnie ++

    

Answer 3

Pensei em mencionar strace, embora essa questão tenha meses de idade. Pode ajudar alguém com um problema semelhante que encontre esta página.

tente.

strace "application"

você também pode fazer

strace -e read,write "application"

para mostrar apenas eventos de leitura / gravação.

O aplicativo será carregado normalmente (embora um pouco mais lento para ser iniciado) e você poderá usá-lo normalmente para acionar o problema. A saída aparecerá no shell que você usou para lançar strace.

O bom do strace é que você pode ver a chamada de função / kernel mais recente no momento em que o aplicativo aciona a lentidão. Você pode achar que, se as suas contas /home estiverem no NFS, o aplicativo está tendo alguma dificuldade com E / S de arquivos sobre NFS por algum motivo.