Charge de serveur élevée - [jbd2 / md1-8] utilisant 99,99% d'E / S

J'ai eu un pic de charge au cours de la dernière semaine. Cela se produit généralement une ou deux fois par jour. J'ai réussi à identifier sur iotop que [jbd2 / md1-8] utilise 99,99% d'E / S. Pendant les temps de chargement élevés, il n'y a pas de trafic élevé vers le serveur.

Les spécifications du serveur sont les suivantes:

• AMD Opteron 8 core
• 16 Go de RAM
• Raid logiciel 1 disque dur 2 x 2 000 Go à 7 200 tr / min
• Cloudlinux + Cpanel
• Mysql est correctement réglé

Mis à part les pointes, la charge est généralement d'environ 0,80 au maximum.

J'ai cherché mais je ne trouve pas exactement ce que fait [jbd2 / md1-8]. Quelqu'un at-il eu ce problème ou quelqu'un connaît-il une solution possible?

Je vous remercie.

MISE À JOUR:

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]

Ce n'est pas vraiment une réponse car il n'y a pas assez de contexte pour donner la cause exacte, mais c'est une description de la façon dont j'ai réussi à suivre cela quand cela m'est arrivé.

J'ai remarqué que je jbd2/md0-8n'arrêtais pas de me montrer en haut de iotop. J'ai regardé /sys/kernel/debug/tracing/events/jbd2pour voir quelles options il y avait pour déterminer ce qui jbd2se faisait.

REMARQUE-1: pour voir la sortie des événements de suivi de débogage cat /sys/kernel/debug/tracing/trace_pipe- je l'ai eu dans le terminal tout en activant / désactivant les traces.

NOTE-2: Pour activer les événements pour le suivi, utilisez par exemple echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Pour désactiver echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.

J'ai commencé par activer /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable- mais il n'y avait rien qui semblait particulièrement intéressant dans la sortie pour cela. J'ai essayé quelques autres événements pour tracer et quand j'ai activé /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enablej'ai vu que cela se produisait à chaque seconde:

# 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

Cela semblait être lié à sync(2)/ fsync(2)/ msync(2), j'ai donc cherché un moyen de lier cela à un processus et j'ai trouvé ceci:

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

Quand je l'ai activé, j'ai vu la sortie suivante:

# 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

Cela m'a donné le nom / id du processus - et après avoir fait un débogage supplémentaire de ce processus ( nzbget), j'ai découvert qu'il le faisait à fsync(2)chaque seconde. Après avoir changé sa configuration ( FlushQueue=nonon documentée, je pense, je l'ai trouvée dans la source) pour l'empêcher de le faire par seconde, fsync(2)le problème a disparu.

Ma version du noyau est. 4.4.6-gentooJe pense qu'il y avait certaines options que j'ai activées (manuellement ou avec make oldconfig) à un moment donné dans la configuration du noyau pour obtenir /sys/kernel/debugces événements - donc si vous ne l'avez pas, regardez peut-être sur Internet pour plus d'informations sur l'activation il.

Cela semble être une chose liée à la mise à jour du journal. Combien de disques sont constitués du RAID logiciel. Pouvez-vous me montrer la commande utilisée pour le créer.

Pouvez-vous également coller la sortie de dumpe2fs. Tout d'abord, identifiez le périphérique physique où vous voyez la charge. Utilisez df pour le savoir. Puis,

dumpe2fs /dev/sdaX > /tmp/dump

Pour votre cas, il peut s'agir de / dev / md0.

Exécutez également ceci.

iostat -xdk 1 25

Au moment du problème élevé d'E / S.

Je ne connais pas cloudlinux mais est l'outil blktrace disponible en dessous.