Имеется сервер с 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
После того, как всё успешно прошло, нужно подмонтировать обратно с использованием нужных опций (я использовал только без барьеров) и не забыть про fstab:
mount -o nobarrier /dev/mapper/vg01-lv01 /u01