У меня на сервере есть диск который периодически вызывает тормоза при обращении. Не на три минуты, но где-то на 30сек (дефолтный таймаут в линухе для сата-устройств). В общем, я решил проблему исключением его из рейда.

Думаю у тебя нечто подобное.

посмотри smart винтов на всякий случай. И проверь все ли обновления есть, иногда такое лечится апдейтами.

Не совсем понял. У тебя был хардверный рейд?

В нашей конфигурации отдельно-взятые диски не используются. Диск, на котором возникает проблема 100% busy (sdb) на самом деле является куском массива RAID10 на дисковой системе, который выдается по оптике. На этом же массиве создано еще несколько виртуальных дисков, которые выданы другим серверам, на одном из которых AIX 6.1, на другом Windows 2008. На них подобных проблем не замечали. Но в любом случае, если что-то не так с диском, то устройство его отрубает и пишет об этом в своем логе. Но лог чист, значит диски все целые...

По этому напрашивается вопрос, может быть это линуксовый софтверный рейд глючит?...

софтварный у меня был рейд. Но дело было не в рейде, а в диске.

может быть это линуксовый софтверный рейд глючит?

может, поэтому обновись.

Но smart глянуть не помешает. Как и диск заменить, если есть свободная замена. А ещё atop -d (или любую другую тулзу) глянуть чтобы убедиться что оно busy, но при этом запросов не выполняет.

Можно попробовать iotop позаписывать, посмотреть что обращалось к дискам, а потом lsof посмотреть куда оно обращалось.

1. Если вы подозреваете диски, то надо проверить нагрузку на диски в этот момент.

2. Проблема точно в дисках, а не в канале к серверу/сетевом соединении? Может просто обновляется ip адрес в этот момент у сервера или у маршрутизатора?

3. Если диски, то посмотрите какой scheduler используется: cat /sys/block/sda/queue/scheduler cat /sys/block/sdb/queue/scheduler

ecли deadline, то это он может подвешивать систему. Лучше сменить на cfq (если он есть в выдаче команды выше).

echo cfq > /sys/block/sda/queue/scheduler echo cfq > /sys/block/sdb/queue/scheduler

4. Возможно в это время выполняется проверка целостности рейда? Если это у вас рейд, а не multipath, например.

5. А что за фс изспользуется?

У меня на сервере есть диск который периодически вызывает тормоза при обращении. Не на три минуты, но где-то на 30сек (дефолтный таймаут в линухе для сата-устройств). В общем, я решил проблему исключением его из рейда.

Может в нем была включена функция энергосбережения и он тупо останавливался, а потом раскручивался?

Но в любом случае, если что-то не так с диском, то устройство его отрубает и пишет об этом в своем логе. Но лог чист, значит диски все целые..

Нифига. Диск может самостоятельно пытаться сделать relocate sector. И если bad секторов много, то это может занимать значительное время. И впоследствии отражаться на скорости доступа. Это будет отражено только в smart.

и он тупо останавливался, а потом раскручивался?

это занимает даже не 10 секунд.

Диск может самостоятельно пытаться сделать relocate sector.

да, но всё равно 3 минуты это больше чем стандартный таймаут 20-30 секунд. Хотя хз что там scsi...

и он тупо останавливался, а потом раскручивался?

это занимает даже не 10 секунд.

У рейда есть задержка, сколько сек. он должен ждать перед обращением к диску после его раскрутки + может быть ошибка позиционирования головок + пр. Все в сумме вполне может набежать приличное время. Но в любом случае какая-то проблема с диском должна быть при таком времени. А это в смарте видно.

короче, заменить менник и дело с концом :)

Кто-нибудь сталкивался с подобным поведением?

Я вчера столкнулся с подобным дедлоком на ZFS: компиляция OpenOffice стоит или ворочается еле-еле. Для сравнения: на UFS2 OOo 3 бодро компилируется за два с половиной часа. Ядра процессора в idle 99% времени, часть процессов, относящихся к perl 5.12 и make чего-то ждёт (wait). После нескольких часов борьбы чего-то с неизвестно чем завершения компиляции не дождался — терпения не хватило, перезагрузил машину.

На томе с ZFS оставалось свободным около 12 ГБ, что должно по идее хватить для сборки, но том до этого использовался под торренты, фрагментация дикая, может в этом вся проблема?

Что у вас с md-томом? Может файловая система не может выделить свободные блоки, и процессы висят в ожидании освободившегося места для записи?

А еще может быть, что очень большие

echo /proc/sys/vm/dirty_background_ratio

echo /proc/sys/vm/dirty_ratio

Если второй во много раз больше внутреннего кеша диска, то большая отложенная запись может очень круто подвесить систему.

diskbusy - все девайсы почти по нулям, кроме sdb (2-й сторидж девайс), который был 100%

а iostat можно? вчастности, любопытно взглянуть на:
tps, Blk_read/s, Blk_wrtn/s, avgrq-sz, avgqu-sz, await, svctm, %util

На Фре нету /proc.

Может sysctl какие глянуть?

Может sysctl какие глянуть?

Параметры называются также:

dirty_background_ratio — процент занятой оперативной памяти начиная с которого pdflush начинает писать на диск

dirty_ratio — соотв. процент, после которого система отказывается писать в память, пока все не будет сброшено на диск

Всякие тесты стоит проводить с обнуленным swappiness (чтобы свопа не было) + overcommit_memory = 2 (чтобы процессам не выдавалось больше памяти, чем есть на самом деле).

md0

большая отложенная запись

хорошо, тогда почему вторая половинка зекрала этому не подвержена?

большая отложенная запись

хорошо, тогда почему вторая половинка зекрала этому не подвержена?

А это был ответ не тс.