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? Это кажется непропорциональным тому, что на самом деле пишется.

Источник

4 ответа

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 (надежный в течение достаточно долгого времени, да. И никакой такой неприятной записи в журнале никогда).
Источник
Другие вопросы по тегам