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.

  • Come testare l'effetto di ionice (contro un dispositivo che utilizza il pianificatore cfq)?
  • Perché un'applicazione pesante ad alta intensità di disco funziona più velocemente su una SAN che su un disco fisico?
  • File system / Opzioni per I / O casuali intenzionali
  • Sintonizzazione dello stack IPv6 di Linux
  • MySQL abbassa il valore wait_timeout a un numero inferiore di connessioni aperte
  • Comportmento di stack tcp solaris con traffico RTT relativamente alto e traffico bursty
  • Esaurire il limite di socket TCP della macchina Linux (~ 70k)?
  • Come si può qualificare un server?
  • 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.