Entendendo a saída do iotop (DTT) no Solaris

Question

Ao executar o iotop da DTT em um pesado servidor Solaris 10, que executa várias zonas com daemons do MySQL instalados, recebo a seguinte saída:

  UID    PID   PPID CMD              DEVICE  MAJ MIN D            BYTES
   70  26636      1 mysqld           sd1      10  64 R           360448
   70  25940      1 mysqld           sd1      10  64 R           530432
    0      5      0 zpool-rpool      sd1      10  64 W         17250816

O que me incomoda aqui é o fato de que zpool-rpool ocupa a maior parte do io. O que posso fazer para ver quais dos processos MySQL ou outros realmente aceitam o IO - um detalhamento mais elaborado? Se zpool-rpool representar "gravações no ZFS", então o iotop realmente não está me ajudando aqui ...:)

Obrigado!

    

Answer 1

Você pode encontrar a recente série de blogs de Brendan Gregg sobre a latência do sistema de arquivos útil. Ele mostra alguns scripts para investigar o uso do sistema de arquivos com o provedor syscall (que deve ser mais confiável para identificar os processos responsáveis do que o provedor io usado pela iotop).

Por exemplo, o script syscall-read-zfs.d mostrado na Parte 4 pode ser facilmente modificado para investigar as gravações e agregar no pid em vez do execname.

A saída deste script também pode ser mais útil que a iotop, pois mostra o número de IOs e a distribuição da latência de IO por processo. Para um banco de dados, a latência de leituras e gravações síncronas são medidas diretas de perda de desempenho - muito mais fáceis de interpretar do que bytes por segundo.

Se você tiver tempo, também recomendo assistir a sua apresentação no BayLISA para uma demonstração prática de como ele vai investigar o MySQL problemas de desempenho de consulta.

    

Answer 2

Se você quiser medir quais aplicativos estão lendo / gravando mais, você deseja medir no nível syscall. No nível do dispositivo, são apenas encadeamentos do kernel que funcionam.