На одному з серверів встановлена найсвіжіша версія Ubuntu на нещодавно придбаний жорсткий диск, для якого в якості базової файлової системою була обрана ext4. За графіком процесорного часу системи моніторингу Zabbix видно, що у сервера високий IOWait. За допомогою утиліт iostat і iotop були виявлені винуватці настільки високого навантаження. Ними виявилися бази MySQL (активно використовуються самим Zabbix 'ом) і процес [jbd2 / dm-0-8]. який виконує функцію журналювання файлової системи ext4. Причому навантаження від другого була в рази більше, тому далі буде опис процесу зниження впливу нової файлової системи на навантаження процесора.
Журнал роботи в новій файлової системи було включено не просто так, а для зниження ризиків втрати даних при всіляких несподіваних збоях в електроживленні. Так як сервер, про який йде мова в цій статті, підключений до побутової електромережі через джерело безперебійного живлення, ймовірність подібної проблеми вкрай мала. Отже, можна практично безболісно позбутися від процедури «логування всього і вся» в процесі роботи системи.
За замовчуванням в Ubuntu встановлений режим journal_incompat_revoke. перевірити поточний стан можна, виконавши від облікового запису root наступну команду (вказати свій розділ з ext4 замість sdX):
Якщо зробити вибірку по іншому параметру, можна буде побачити, чи ведеться журнал:
Висновок буде містити рядок з «has_journal«, якщо це так.
Переводимо файлову систему в режим journal_data_writeback. який залишає журнал лише для метаданих і тим самим помітно прискорює продуктивність файлової системи:
- Завантажуємося з LiveCD / LiveUSB або будь-яким іншим способом, щоб можна було демонтувати розділ з файловою системою, що вимагає внесення змін
- Вимикаємо журнал:
- Міняємо режим журналювання
- запускаємо перевірку
- Перезавантажуємося
- Перевіряємо, застосували зміни, командами
Нижче представлені порівняльні графіки процесорного часу і дискових операцій до і після відключення журналу:
Трохи теорії про можливі режимах роботи файлової системи, для тих хто не втомився:
* 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.
Навігація по публікаціям