Cитуация такая -- мунин и top показывают, что есть iowait-ы, хотя раньше их не было. Я начал искать виновника и выяснил -- это kjournald. Причем, происходит это при высокой нагрузке то ли мускула то ли nginx.

по времени появление высоких iowait оно совпало с добавлением нескольких тривиальных select/update к скриптам, однако все они (я это проверил) пробегаются (модифицируют) по проиндексированным данным, без чтения строк подряд. Поэтому, я подозреваю, что дело не в них.

нагугленное
# dmesg | egrep "READ|WRITE|dirtied" | egrep -o '([a-zA-Z]*)' | sort | uniq -c | sort -rn | head
выдает:
1939 on
1939 md
1546 block
1546 WRITE
1438 kjournald
393 inode
393 dirtied
346 nginx
344 gif
64 mysqld

iotop в основном показывает нагрузку kjournald и md0_raid, которая, насколько я понимаю, является прямым следствием журнала.

# iotop -b -P -o -d 1
Total DISK READ: 0 B/s | Total DISK WRITE: 0 B/s
PID USER DISK READ DISK WRITE SWAPIN IO COMMAND
1060 root 0 B/s 0 B/s 0.00 % 62.35 % [kjournald]
1030 root 0 B/s 0 B/s 0.00 % 28.17 % [md0_raid1]
...секунд 5 ноль активности и потом повтор такой-же бодяги.

говорят, отключить kjournajd невозможно, но может можно его как-то его заставить свопить не раз в 5 секунд, а раз часов в 5 или как-нибудь по крону, ночью? Что вообще можно с этим сделать?

гипотеза --
Все правильно kjournald свопит раз в 5 секунд, но ведь раньше таких iowait не было! Я делаю вывод, что раньше нужно было меньше свопить. А разбухла там только mysql табличка. И отсюда я делаю вывод, что, наверное, несмотря на то, что mysql держит файлы таблиц открытыми, на уровне файловой системы эти файлы скидываются в журнал, но высокой io активности mysql нет, поскольку он их как-то кэширует. какая-то такая гипотеза...

что с этим делать?