На одном из серверов установлена свежая версия Ubuntu на недавно приобретенный жесткий диск, для которого в качестве базовой файловой системой была выбрана ext4. По графику процессорного времени системы мониторинга Zabbix видно, что у сервера высокий IOWait. С помощью утилит iostat и iotop были выявлены виновники столь высокой нагрузки. Ими оказались базы MySQL (активно используемые самим Zabbix‘ом) и процесс [jbd2/dm-0-8], который выполняет функцию журналирования файловой системы ext4. Причем нагрузка от второго была в разы больше, поэтому дальше будет описание процесса снижения воздействия новой файловой системы на нагрузку процессора.
Журналирование в новой файловой системе было включено не просто так, а для снижения рисков потери данных при всевозможных неожиданных сбоях в электропитании. Так как сервер, о котором идет речь в этой статье, подключен к бытовой электросети через источник бесперебойного питания, вероятность подобной проблемы крайне мала. Следовательно, можно практически безболезненно избавиться от процедуры «логирования всего и вся» в процессе работы системы.
Дисклеймер: последующие операции вы делаете на свой страх и риск, автор не несет никакой ответственности за убитые жесткие диски и потерянные важные данные.
По умолчанию в Ubuntu установлен режим journal_incompat_revoke, проверить текущее состояние можно, выполнив от учетной записи root следующую команду (указать свой раздел с ext4 вместо sdX):
dumpe2fs /dev/sdX |grep journal
Если сделать выборку по другому параметру, можно будет увидеть, ведется ли журнал:
dumpe2fs /dev/sdX |grep features
Вывод будет содержать строку с «has_journal«, если это так.
Переводим файловую систему в режим journal_data_writeback, который оставляет журналирование лишь для метаданных и тем самым заметно ускоряет производительность файловой системы:
- Загружаемся с LiveCD/LiveUSB или любым другим способом, чтобы можно было размонтировать раздел с файловой системой, требующей внесения изменений
- Выключаем журнал:
tune2fs -O ^has_journal /dev/sdX - Меняем режим журналирования
tune2fs -o journal_data_writeback /dev/sdX - Запускаем проверку
e2fsck -f /dev/sdX - Перезагружаемся
- Проверяем, применились ли изменения, командами
dumpe2fs /dev/sdX |grep journal dumpe2fs /dev/sdX |grep features
Ниже представлены сравнительные графики процессорного времени и дисковых операций до и после отключения журнала:
До
После
До
После
До
После
* writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode — metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.* ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it’s time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.* journal mode
data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it outperforms all others modes. Curently ext4 does not have delayed allocation support if this data journalling mode is selected.
Ссылки: