Carico elevato del server - [jbd2 / md1-8] utilizzando IO 99,99%

Ho avuto un picco di carico durante l'ultima settimana. Questo di solito si verifica una o due volte al giorno. Sono riuscito a identificare da iotop che [jbd2 / md1-8] utilizza il 99,99% di IO. Durante i tempi di caricamento elevati non c'è traffico elevato verso il server.

Le specifiche del server sono:

• AMD Opteron 8 core
• 16 GB di RAM
• Raid software HDD 2x2.000 GB 7.200 RPM 1
• Cloudlinux + Cpanel
• Mysql è correttamente sintonizzato

A parte i picchi, il carico di solito è di circa 0,80 al massimo.

Ho cercato in giro ma non riesco a trovare esattamente ciò che [jbd2 / md1-8] fa esattamente. Qualcuno ha avuto questo problema o qualcuno conosce una possibile soluzione?

Grazie.

AGGIORNARE:

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]

Questa non è davvero una risposta in quanto non c'è abbastanza contesto per dare la causa esatta, ma è una descrizione di come sono riuscito a rintracciarlo quando è successo a me.

Ho notato che jbd2/md0-8continuavo a presentarmi in cima a iotop. Ho guardato dentro /sys/kernel/debug/tracing/events/jbd2per vedere quali opzioni ci sono per determinare cosa jbd2stava facendo.

NOTA-1: Per vedere l'output degli eventi di traccia del debug cat /sys/kernel/debug/tracing/trace_pipe- ho avuto questo in esecuzione nel terminale mentre abilitavo / disabilitavo le tracce.

NOTA-2: per abilitare gli eventi per la traccia utilizzare ad es echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. Per disabilitare echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable.

Ho iniziato abilitando /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable, ma non c'era nulla di particolarmente interessante nell'output. Ho provato a tracciare alcuni altri eventi e quando l'ho attivato /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enableho visto che si stava verificando ogni secondo:

# 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

Sembrava che fosse correlato a sync(2)/ fsync(2)/ msync(2), quindi ho cercato un modo per collegarlo a un processo e ho trovato questo:

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

Quando l'ho abilitato ho visto il seguente output:

# 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

Questo mi ha dato il nome del processo / id - e dopo aver fatto un po 'più di debug di questo processo ( nzbget) ho scoperto che stava facendo fsync(2)ogni secondo. Dopo che ho cambiato la sua configurazione ( FlushQueue=nocredo, senza documenti, l'ho trovata nella fonte) per impedirgli di farlo al secondo, fsync(2)il problema è andato via.

La mia versione del kernel è 4.4.6-gentoo. Penso che ci fossero alcune opzioni che ho abilitato (manualmente o con make oldconfig) ad un certo punto nella configurazione del kernel per ottenere /sys/kernel/debugcon questi eventi - quindi se non ce l'hai forse guardati su Internet per ulteriori informazioni sull'abilitazione esso.

Questa sembra essere una cosa relativa all'aggiornamento del journal. Di quanti dischi è composto il software RAID. Puoi mostrarmi il comando usato per crearlo.

Puoi anche incollare l'output di dumpe2fs. Innanzitutto, identifica il dispositivo fisico in cui vedi caricare. Usa df per saperlo. Poi,

dumpe2fs /dev/sdaX > /tmp/dump

Nel tuo caso, potrebbe essere / dev / md0.

Inoltre, esegui questo.

iostat -xdk 1 25

Al momento del problema dell'IO elevato.

Non conosco cloudlinux ma è lo strumento blktrace disponibile sotto di esso.