Kjournald причины для высокого использования

Я пытаюсь понять, почему kjournaldсхожу с ума на моей машине. Это 8-ядерная коробка с большим количеством памяти. У него загрузка процессора ~ 50%.

Похоже, что iotop не указывает на какие-то конкретные процессы - некоторые пакеты записей здесь и там (в основном запуск cron, генерируется некоторая статистика мониторинга и т. Д.) Когда я использовал sys/vm/block_dumpдля сбора статистики записи, я получил списки, подобные этому:

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действия просто пишут.

Почему это происходит? Что еще я должен посмотреть, чтобы немного ограничить активность kjournald? Это кажется непропорциональным тому, что на самом деле пишется.

kjournaldотвечает за журнал ext3 (ведение журнала файловой системы). Известно, что при определенных нагрузках используется много ресурсов процессора. Не нужно ничего делать, кроме как использовать другую файловую систему или отключить ведение журналов (эффективно делая fs ext2).

Теоретически вы можете использовать один из других режимов журналирования ext3 и проверить, снижается ли загрузка процессора, но помните, что каждый метод является компромиссом в отношении безопасности данных, записываемых на диск. Вы заказали режим, режим обратной записи и режим «все».

1. Упорядочено: журнал только метаданные, но гарантирует, что данные, относящиеся к метаданным, сохраняются до внесения изменений метаданных в журнал.
2. Обратная запись: только метаданные журнала, но нет гарантии, что данные будут сохранены до фиксации журнала.
3. журнал: все журнализируется, данные и метаданные. Это может быть медленно, но YMMV.

Вы устанавливаете режим с помощью опции data=при монтаже системы, например data=ordered.

По умолчанию ваша файловая система ext3 будет монтироваться с включенным временем. Каждый раз, когда файл или каталог читается / обращается к ним, файловая система должна записывать обратно на диски, чтобы обновить эту временную запись. Это означает, что даже если ваша рабочая нагрузка в основном основана на чтении, вам все равно придется нажимать на диски, чтобы обновить время доступа для каждого файла и каталога, и я думаю, почему ваш kjournaldпроцесс записывал так много блоков.

Отключение atime приведет к значительному увеличению производительности, но нарушит соответствие POSIX. Посмотрите эту статью в Википедии, чтобы обсудить критику atime.

Чтобы отключить время, просто добавьте noatimeв опции монтирования для вашей файловой системы, или вы можете перемонтировать, как предложено poige. Вот пример для вашей корневой файловой системы:

mount -o remount,noatime /

Если безупречность данных не важна: сделайте это

iostat -o -a

Убедитесь, что это действительно kjournald. Это то, что приводит к краху моего сервера.

Изменение жесткого диска на SSD будет работать.

Когда вы видите, что kjournald пишет 5-10 МБ данных, вы делаете

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

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

где sda1 - имя вашего раздела

Сообщите результат в комментарии, чтобы я мог проверить.

Не для того, чтобы сделать, просто чтобы упомянуть:

1. mount -oremount,noatime /fs/being_over/journaled- как быстрый угадайку (ты не показал нам, как ты mountвсе равно выглядишь)
2. Попробуйте уменьшить размер журнала ( tune2fs -J …)
3. Переключитесь на Reiser3 (надежный в течение достаточно долгого времени, да. И никакой такой неприятной записи в журнале никогда.)