kjournald razones para un alto uso

Estoy tratando de entender por qué se está kjournaldvolviendo loco en mi máquina. Es una caja de 8 núcleos con mucha memoria. Tiene ~ 50% de carga de CPU.

El iotop no parece apuntar a ningún proceso específico: algunas ráfagas de escrituras aquí y allá (principalmente inicio cron, algunas estadísticas de monitoreo generadas, etc.) Cuando solía sys/vm/block_dumpreunir las estadísticas de escritura, obtuve listas como esta:

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

Donde las kjournaldacciones son solo ESCRITAS.

¿Por qué está pasando eso? ¿Qué más debo mirar para limitar un poco la actividad de kjournald? Parece desproporcionado a lo que realmente se está escribiendo.

kjournaldes responsable del diario de ext3 (sistema de archivos de diario). Se sabe que usa mucha CPU bajo ciertas cargas. No hay mucho que hacer, excepto usar otro sistema de archivos o deshabilitar el registro en diario (efectivamente haciendo el fs ext2).

Teóricamente, puede usar uno de los otros modos de registro en diario ext3 y verificar si el uso de la CPU disminuye, pero recuerde que cada método es un compromiso sobre la seguridad de los datos que se escriben en el disco. Has ordenado el modo, el modo de reescritura y el modo 'todo'.

1. Pedido: solo metadatos del diario, pero asegura que los datos relacionados con los metadatos se guarden antes de confirmar los cambios de metadatos en el diario.
2. reescritura: solo metadatos del diario, pero no tiene garantía de que los datos se guarden antes de la confirmación del diario.
3. diario: todo está registrado, datos y metadatos. Puede ser lento pero YMMV.

Establece el modo usando la opción data=al montar el sistema, como data=ordered.

Por defecto, su sistema de archivos ext3 se montará con los atimes activados. Cada vez que se lee / accede a un archivo o directorio, el sistema de archivos tendrá que volver a escribir en los discos para actualizar este registro atime. Esto significa que incluso si su carga de trabajo se basa principalmente en la lectura, deberá presionar los discos para actualizar los tiempos de acceso de cada archivo y directorio, y esta es mi suposición sobre por qué su kjournaldproceso estaba escribiendo tantos bloques.

Desactivar atime dará un gran impulso al rendimiento, pero romperá el cumplimiento de POSIX. Mira este artículo de Wikipedia para una discusión sobre las críticas de atime's.

Para apagar a veces simplemente agregue noatimea las opciones de montaje para su sistema de archivos, o puede volver a montar como lo sugiere poige. Aquí hay un ejemplo para su sistema de archivos raíz:

mount -o remount,noatime /

Si la perfección de los datos no es importante: haga esto

iostat -o -a

Asegúrate de que sea realmente kjournald. Es lo que hace que mi servidor se bloquee.

Cambiar el disco duro a SSD funcionaría.

Cuando veas kjournald escribiendo 5-10MB de datos que haces

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

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

donde sda1 es el nombre de su partición

Informe el resultado en un comentario para que pueda verificarlo más a fondo.

No en el orden de hacer, solo para mencionar:

1. mount -oremount,noatime /fs/being_over/journaled- como una suposición rápida (de mounttodos modos no nos mostró cómo se ve)
2. Intente reducir el tamaño del diario ( tune2fs -J …)
3. Cambie a Reiser3 (robusto durante bastante tiempo, sí. Y no hay un diario tan desagradable nunca).