Имеется сервер с Red Hat 6.9 в ЦОД, на котором крутится БД MySQL. Периодически начались проблемы с постоянным процессом JBD2/dm-2-8 , который отжирал весь IOwait (значения были под сотку).
В результате изучения и поиска информации по данному вопросу выявил следующее:
Сам по себе процесс записи в журнал не должен вызывать опасений – это нормально, что он пишет. Другой вопрос, что его вызывает так часто и почему высокий IOwait…
Так как в движке InnoDB работающего MySQL есть своё журналирование, то в системе его можно просто отключить без особых опасений, т.к. сервер в ЦОДе, и в случае сбоя ОС не должна аварийно завершить свою работу. Более подробно о нюансах отключения можно погуглить.
Теперь подбираемся к вопросу о непосредственном отключении журналирования. Рассмотрим основные опции, которые дадут нам также производительность:
data={ordered|journal|writeback}
{в журнал пишутся только мета-данные, данные полностью журналируются, журнал не ведётся}
commit=5 {интервал между sync, по дефолту 5, можно увеличить)
barrier | nobarrier {барьеры для упорядочивания запросов записи; можно отключить для прироста производительности}
Теперь, когда разобрались с основной теорией, можно приступить к практике:
Проверяем, что БД на отдельном разделе (не на системном):
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
45G 11G 32G 26% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
/dev/sda1 477M 97M 355M 22% /boot
/dev/mapper/vg01-lv01
689G 55G 600G 9% /u01
Нас интересует /dev/mapper/vg01-lv01 и раздел /u01
Так как используется LVM, проверяем, что в VG только нужный нам диск:
pvscan
File descriptor 63 (pipe:[575263301]) leaked on pvscan invocation. Parent PID 18901: bash
PV /dev/sdb1 VG vg01 lvm2 [700.00 GiB / 0 free]
PV /dev/sda2 VG VolGroup lvm2 [24.51 GiB / 0 free]
PV /dev/sda3 VG VolGroup lvm2 [25.00 GiB / 0 free]
Total: 3 [749.50 GiB] / in use: 3 [749.50 GiB] / in no VG: 0 [0 ]
Как видно из выхлопа выше, в VG vg01 только один диск sdb1.
Останавливаем сервис MySQL и проверяем, что раздел больше никем не используется:
lsof | grep /u01
Если есть процессы, останавливаем их или kill -9
Теперь отмонтируем раздел (принудительно лучше не использовать):
umount /dev/mapper/vg01-lv01
Меняем тип журнала:
tune2fs -o journal_data_writeback /dev/mapper/vg01-lv01
tune2fs -O ^has_journal /dev/mapper/vg01-lv01
И обязательно запускаем проверку:
e2fsck -f /dev/mapper/vg01-lv01
Если пишет:
e2fsck 1.41.12 (17-May-2010)
/dev/mapper/vg01-lv01 is in use.
e2fsck: Cannot continue, aborting.
То смотреть в сторону lsof, что\кто занимает нужный раздел или так:
fuser -mv /dev/mapper/vg01-lv01
После того, как всё успешно прошло, нужно подмонтировать обратно с использованием нужных опций (я использовал только без барьеров):
mount -o nobarrier /dev/mapper/vg01-lv01 /u01