Carga alta do servidor - [jbd2 / md1-8] usando 99,99% de E / S

Eu tenho tido um pico de carga na última semana. Isso geralmente ocorre uma ou duas vezes por dia. Eu consegui identificar no iotop que [jbd2 / md1-8] está usando 99,99% de IO. Durante os tempos de carregamento alto, não há tráfego intenso para o servidor.

As especificações do servidor são:

• AMD Opteron 8 núcleo
• 16 GB de RAM
• 2x2.000 GB 7.200 RPM HDD Raid Software 1
• Cloudlinux + Cpanel
• O MySQL está devidamente ajustado

Além dos picos, a carga geralmente é de aproximadamente 0,80.

Eu procurei, mas não consigo encontrar o que [jbd2 / md1-8] faz exatamente. Alguém já teve esse problema ou alguém conhece uma possível solução?

Obrigado.

ATUALIZAR:

TIME        TID     PRIO     USER    DISK READ    DISK WRITE    SWAPIN  IO       COMMAND
16:05:36     399     be/3    root    0.00 B/s      38.76 K/s    0.00 %  99.99 %  [jbd2/md1-8]

Esta não é realmente uma resposta, pois não há contexto suficiente para fornecer a causa exata, mas é uma descrição de como eu consegui rastrear isso quando aconteceu comigo.

Notei que eu jbd2/md0-8continuava aparecendo no topo iotop. Eu olhei /sys/kernel/debug/tracing/events/jbd2para ver quais opções existem para determinar o que jbd2estava fazendo.

NOTA-1: Para ver a saída para eventos de rastreamento de depuração cat /sys/kernel/debug/tracing/trace_pipe- eu tinha isso em execução no terminal ao ativar / desativar rastreamentos.

NOTA-2: Para ativar eventos para rastreamento, por exemplo echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Desativar echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.

Comecei ativando /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable- mas não havia nada que parecesse particularmente interessante no resultado. Tentei alguns outros eventos para rastrear e, quando habilitei /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable, vi que estava ocorrendo a cada segundo:

# cat /sys/kernel/debug/tracing/trace_pipe
...
jbd2/md0-8-2520  [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0
jbd2/md0-8-2520  [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0
jbd2/md0-8-2520  [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0

Parecia que estava relacionado a sync(2)/ fsync(2)/ msync(2), então procurei alguma maneira de vincular isso a um processo e encontrei o seguinte:

# find /sys/kernel/debug/tracing/events/ | grep sync.*enable
...
/sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
...

Quando o habilitei, vi a seguinte saída:

# cat /sys/kernel/debug/tracing/trace_pipe
...
      nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0
      nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0
      nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0
      nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0

Isso me deu o nome do processo / id - e depois de fazer mais algumas depurações desse processo ( nzbget), descobri que estava fazendo a fsync(2)cada segundo. Depois que eu mudei sua configuração ( FlushQueue=noacho que não documentada, achei na fonte) para impedir que isso acontecesse por segundo, fsync(2)o problema desapareceu.

Minha versão do kernel é 4.4.6-gentoo. Acho que havia algumas opções que habilitei (manualmente ou com make oldconfig) em algum momento da configuração do kernel para obter /sys/kernel/debugesses eventos - então, se você não tiver, talvez procure na Internet para obter mais informações sobre como habilitar isto.

Parece ser uma coisa relacionada à atualização do diário. De quantos discos o RAID de software é composto. Você pode me mostrar o comando usado para criá-lo.

Você também pode colar a saída dumpe2fs. Primeiro, identifique o dispositivo físico em que você vê a carga. Use df para saber isso. Então,

dumpe2fs /dev/sdaX > /tmp/dump

Para o seu caso, pode ser / dev / md0.

Além disso, execute isso.

iostat -xdk 1 25

No momento da edição de alto IO.

Eu não conheço o cloudlinux, mas é a ferramenta blktrace disponível nele.