kjournald motivi per un utilizzo elevato

Sto cercando di capire perché il kjournald è impazzito sulla mia macchina. Si tratta di una scatola da 8 core con un carico di memory. Ha il ~ 50% di CPU.

L'iotop non sembra indicare alcun process specifico – alcuni scatti di scritture qua e là (principalmente cron, alcune statistiche di monitoraggio generate, ecc.) Quando ho usato sys/vm/block_dump per raccogliere le statistiche di scrittura, ho degli elenchi come questo:

 kjournald(1352): 1909 sendmail(28934): 13 cron(28910): 12 cron(28912): 11 munin-node(29015): 3 cron(28913): 3 check_asterisk_(28917): 3 sh(28917): 2 munin-node(29022): 2 munin-node(29021): 2 

Dove le azioni kjournald sono solo WRITEs.

Perché succede? Cosa dovrei guardare per limitare un po 'l'attività kjournald? Sembra sproporzionato di ciò che viene effettivamente scritto.

4 Solutions collect form web for “kjournald motivi per un utilizzo elevato”

kjournald è responsabile del diario di ext3 (file system di journaling). È noto che utilizza un sacco di CPU sotto certi carichi. Non c'è molto da fare se non utilizzare un altro filesystem o distriggersre il journaling (rendendo effettivamente la fs ext2).

Teoricamente è ansible utilizzare una delle altre modalità di journaling ext3 e controllare se l'utilizzo della CPU diminuisce, ma ricorda che each metodo è un compromesso sulla sicurezza dei dati scritti sul disco. Hai ordinato la modalità, la modalità di scrittura e la modalità "tutto".

  1. Ordinato: metadati solo per i giornali, ma assicura che i dati relativi a un metadato vengono salvati prima di commettere le modifiche dei metadati al diario.
  2. writeback: il journal metadata solo, ma non ha alcuna garanzia che i dati siano salvati prima che il commit del journal.
  3. giornale: tutto è giornalizzato, dati e metadati. Può essere lento ma YMMV.

È ansible impostare la modalità utilizzando i data= opzione data= durante il assembly del sistema, come i data=ordered .

Per impostazione predefinita il filesystem ext3 verrà montato con atimes acceso. Ogni volta che un file o una directory viene letto o acceduto, il filesystem dovrà tornare ai dischi per aggiornare questo record atime. Ciò significa che anche se il tuo carico di lavoro è in gran parte letto basato si dovrà ancora colpire i dischi per aggiornare i tempi di accesso di each directory di file e questa è la mia ipotesi sul perché il tuo process kjournald stava scrivendo così tanti blocchi.

Distriggersre l'atime fornirà una grande spinta alle performance ma interromperà la conformità POSIX. Guarda questo articolo di Wikipedia per qualche discussione intorno alla critica di Atime.

Per distriggersre atimes è sufficiente aggiungere noatime alle opzioni di assembly del file system oppure è ansible rimontare come suggerito da poige. Ecco un esempio per il tuo filesystem root:

 mount -o remount,noatime / 

Se la perfezione dei dati non è importnte: fare questo

 iostat -o -a 

Assicurati che sia davvero kjournald. Quello che provoca il crash del mio server.

Cambiare il disco rigido su SSD functionrebbe.

Quando vedi kjournald scrivere 5-10MB di dati che fai

http://ubuntuforums.org/showthread.php?t=56621

 sudo tune2fs -O ^has_journal /dev/sda1 sudo e2fsck /dev/sda1 

where sda1 è il nome della partizione

Il risultato del rapporto in commento in modo da poter controllare ulteriormente.

Non nell'ordine da fare, per citare:

  1. mount -oremount,noatime /fs/being_over/journaled – come un colpo di scatto rapido (non ci hai mostrato come sembra comunque il tuo mount )
  2. Prova a ridurre la dimensione del journal ( tune2fs -J … )
  3. Passare a Reiser3 (robusto per un bel po 'di tempo, sì, e nessuna giornata così rapida .)
Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.