"притормозы" системы при коротких всплесках дисковой активности
Доброго времени суток всем,
Есть Debian etch/lenny с ядрами 2.6.28 (с kernel org) и lenny
дистрибутивным 2.6.26.
Система стоит на серверах Xeon quad-core 2.0 ghz, 8Gb Ram, но с обычными
SATA винчестерами.
Дисковая подсистема устроена следующим образом: hda/hdb > md1raid > lvm > kcryptd > ext3
На серверах крутятся несколько java-приложений, которые помимо всего
прочего пишут некий
state log раз в секунду (строчка параметров приложения, вроде vmstat).
Так же, параллельно, пишется простая статистика в виде top/vmstat в
обычный файл. Тоже раз в секунду. (обычный цикл в баше с
перенаправлением в файл).
Проблема заключается в следующем:
Иногда ежесекундная запись в файл "замораживается" на 5-8 секунд. Иногда
так отмирает запись файла только для этого приложения, а все остальные
продолжают писать нормально. Иногда "замораживается" все, что писало
логи в системе. Т.е. такое впечатление, что система полностью замерла на
5-8 секунд, а потом начала работать снова. Такое бывает несколько раз в
день на разных серверах с идентичной конфигурацией.
Исследование статистики показало, что в моменты таких притормозов
происходит рост i/o blocked процессов (штук 6-10), вырастает wait cpu
usage, vmstat показывает output на диск 60-80 мегабайт в секунду
(непродолжительный) и иногда можно заметить что Writeback из /proc/meminfo тоже
держит в себе 60-80 мегабайт.
Надо сказать, что ничего такого интесивного на диск не пишется, работа с
диском в целом незначительна. Нет баз данных, и т.д. Моменты таких
притормозов не совпадают с моментами ротации логов.
Т.е. очень похоже (особенно по большим значениям в Writeback) что просто
происходит pdflush кэшей на диск, которые накопились за время работы.
Такое впечатление, что наступает момент сбросить кэши на диск и процессы просто блокируются по i/o.
Что пробовал:
1. Отключать/включать atime в ext3
2. Отключать криптование диска через kcryptd
3. Разные системы/ядра (etch/lenny, 2.6.28/2.6.26).
4. Тюнить параметры pdflush, с учетом большого количества памяти
уменьшал до 1 параметры /proc/sys/vm/dirty_ratio и
/proc/sys/vm/dirty_background_ratio. Уменьшал
/proc/sys/vm/dirty_writeback_centisecs до 5 секунд.
Ничего не помогает. Система как "подмерзала", так и "подмерзает". Более
того, игры с dirty_*ratio параметрами вообще приводили к печальным
последствиям, появились непонятные всплески runnable процессов
java-приложений. Т.е. ни с того ни с чего 150-160 тридов явы
активировались, делали la на систему и исчезали. После возврата
dirty_*ratio в factory default - такое поведение исчезло.
На что можно посмотреть, что покрутить? Есть ли что-то вроде дискового
шейпера в системе? Когда необходимо записать единоразово 80 мегабайт, то
не делать это мгновенно, а размазать по времени, пусть лучше пишется
медленно, но не блокирует систему.
Или я просто уперся в лимит по винту и никакими софтовыми тюнингами это
не решить, только заменой на SCSI?
Буду благодарен за любые идеи.
--
WBR,
Alex
Reply to: