web-dev-qa-db-fra.com

Charge de serveur élevée - [JBD2 / MD1-8] en utilisant 99,99% IO

J'ai eu une charge de pointe au cours de la dernière semaine. Cela se produit généralement une ou deux fois par jour. J'ai réussi à identifier de iotop que [JBD2/MD1-8] utilise 99,99% IO. Pendant les heures de charge élevées, il n'y a pas de trafic élevé sur le serveur.

Les spécifications de serveurs sont:

  • AMD OPTERON 8 CORE
  • 16 gb bélier
  • 2x2.000 GB 7.200 RPM Software HDD RAID 1
  • CloudLinux + cpanel
  • Mysql est correctement réglé

Outre les pointes, la charge est généralement d'environ 0,80 au plus.

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

Merci.

METTRE À 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]
linuxsoftware-raidhigh-load
12
Alex

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é mon jbd2/md0-8 Continué à montrer en haut de iotop. J'ai regardé dans /sys/kernel/debug/tracing/events/jbd2 Pour voir quelles options il doit déterminer ce que jbd2 Faisait.

NOTE-1: Pour voir la sortie des événements de traçage de débogage cat /sys/kernel/debug/tracing/trace_pipe - J'avais cela en cours d'exécution en terminal tout en permettant/désactiver des traces.

Note-2: Pour activer les événements d'utilisation de la traçabilité par ex. echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Désactiver echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.

J'ai commencé par activation /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable - mais il n'y avait rien qui semblait particulièrement intéressant dans la production. J'ai essayé quelques autres événements à tracer et quand j'ai activé /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable J'ai vu qu'il 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 ressemblait à c'était lié à sync(2)/fsync(2)/msync(2) _, donc j'ai cherché un moyen de relier cela à un processus et 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 de processus/ID - et après avoir fait plus de débogage de ce processus (nzbget) j'ai découvert qu'il faisait fsync(2) chaque seconde. Après avoir changé de config (FlushQueue=no, Je pense que je pense, trouvé dans la source) de l'arrêter de le faire par seconde fsync(2) Le problème s'est éloigné.

Ma version de kernel est 4.4.6-gentoo. Je pense qu'il y avait quelques options que j'ai activées (manuellement ou avec make oldconfig) À un moment donné dans le kernel config pour obtenir /sys/kernel/debug Avec ces événements - donc Si vous ne le faites pas, il suffit de regarder sur Internet pour plus d'informations sur l'activation.

18
Iwan Aucamp

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

Pouvez-vous aussi coller la sortie du dukette2fs. Tout d'abord, identifiez le dispositif physique où vous voyez la charge. Utilisez DF pour le savoir. Puis,

dumpe2fs /dev/sdaX > /tmp/dump

Pour votre cas, cela pourrait être/dev/md0.

Aussi, courez ceci.

iostat -xdk 1 25

Au moment de la hauteur IO problème.

Je ne connais pas CloudLinux mais est l'outil blktrace disponible sous elle.

1
Soham Chakraborty