Доброго времени суток всем, Есть 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 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org