15 votes

kjournald : raisons de l'utilisation élevée

J'essaie de comprendre pourquoi kjournald qui devient folle sur ma machine. C'est une machine à 8 cœurs avec beaucoup de mémoire. Il y a ~50% de charge du processeur.

L'iotop ne semble pas pointer vers des processus spécifiques - quelques rafales d'écritures ici et là (principalement le démarrage de cron, la génération de statistiques de surveillance, etc. sys/vm/block_dump pour rassembler les statistiques d'écriture, j'ai obtenu des listes comme celle-ci :

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

kjournald les actions ne sont que des ECRITURES.

Pourquoi cela se produit-il ? Que dois-je faire d'autre pour limiter un peu l'activité de kjournald ? Elle semble disproportionnée par rapport à ce qui est réellement écrit.

15voto

coredump Points 12455

kjournald est responsable du journal de ext3 (système de fichiers de journalisation). Il est connu pour utiliser beaucoup de CPU sous certaines charges. Il n'y a pas grand chose à faire à part utiliser un autre système de fichiers ou désactiver la journalisation (ce qui rend le fs ext2).

Théoriquement, vous pouvez utiliser l'un des autres modes de journalisation d'ext3 et vérifier si l'utilisation du CPU diminue, mais n'oubliez pas que chaque méthode est un compromis sur la sécurité des données écrites sur le disque. Vous avez le mode ordonné, le mode writeback et le mode 'tout'.

  1. Commandé : Le journal ne contient que des métadonnées, mais il garantit que les données liées à une métadonnée sont sauvegardées avant de transmettre les changements de métadonnées au journal.
  2. le retour en arrière : journal que les métadonnées, mais n'a aucune garantie que les données sont enregistrées avant le journal commit.
  3. journal : tout est consigné, les données et les métadonnées. Cela peut être lent, mais c'est une question de jugement.

Vous définissez le mode à l'aide de l'option data= lors du montage du système, comme data=ordered .

4voto

Evan Borgstrom Points 141

Par défaut, votre système de fichiers ext3 est monté avec l'option atimes activée. Chaque fois qu'un fichier ou un répertoire est lu/accédé, le système de fichiers devra réécrire sur les disques pour mettre à jour cet enregistrement atime. Cela signifie que même si votre charge de travail est principalement basée sur la lecture, vous aurez toujours besoin de frapper les disques pour mettre à jour les temps d'accès de chaque fichier et répertoire. kjournald Le processus écrivait tellement de blocs.

Désactiver les atime's permet d'améliorer considérablement les performances, mais n'est pas conforme à POSIX. Consultez le site cet article de Wikipedia pour une discussion autour de la critique des atime's.

Pour désactiver atimes, il suffit d'ajouter noatime aux options de montage pour votre système de fichiers, ou vous pouvez remonter comme suggéré par poige. Voici un exemple pour votre système de fichiers racine :

mount -o remount,noatime /

1voto

tim_wonil Points 1148

Si la perfection des données n'est pas importante : faites ceci

iostat -o -a

Assurez-vous qu'il s'agit bien de kjournald. C'est ce qui provoque le crash de mon serveur.

Changer le disque dur en SSD pourrait fonctionner.

Quand vous voyez que kjournald écrit 5-10MB de données vous faites

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

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

où sda1 est le nom de votre partition

Rapportez le résultat dans le commentaire pour que je puisse vérifier plus avant.

0voto

cyphun Points 53

Pas dans l'ordre de faire, juste de mentionner :

  1. mount -oremount,noatime /fs/being_over/journaled - comme une rapide supposition (vous ne nous avez pas montré ce que votre mount de toute façon)
  2. Essayez de réduire la taille du journal ( tune2fs -J … )
  3. Passer à Reiser3 (robuste pendant un bon bout de temps, oui. Et jamais un journal aussi méchant.)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X