Назад | Перейти на главную страницу

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's.

Чтобы выключить время, просто добавьте 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 (Да, достаточно долгое время, и никогда не было такого неприятного дневника.)