«echo 0 > /proc/sys/kernel/hung_task_timeout_secs» disables this message.

И в ту же степь - на что влияет /sys/block/sda/device/queue_depth (в Gentoo - 64, в CentOS - 256) и как настраивается (и тоже на что влияет) /sys/block/sda/device/queue_type (simple и ordered, соответственно)

Насколько я понял - это макс кол-во секунд задачи в состоянии 'D'

После этого таймаута он так ругается.

Выставил 0 - всё равно под утро машина зависла (с какими симптомами - х.з., т.к. начало в dmesg затерялось за бесчислеными сообщениями об ошибке FS - это уже следствие вырубания контроллера).

Прописал теперь 300 и сделал ежеминутный сброс dmesg'а на удалённую машину по sshfs. Посмотрим.

Может быть проблема в ядре + bigmem.

Вот пример решения

>ее единственное решение (судя по форумам и блога) - апдейт на ядро выше 2.6.29 :(

2.60.31-r4 стояло. До -r6 вчера обновился, но утром всё равно повисло :-/

...

Сейчас, с 300 сек. часа четыре уже работает пока, но это ни о чём не говорит, учитывая, что до позавчерашнего дня машина и со старыми настройками 37 дней проработала, пока не зависла.

...

Блин, предыдущий сервер у меня за 6 лет вис только когда системный диск бэдблоками сыпался...

мож с железом что не так?

лучше возьми провод и сделай serial console на другой сервер - увидишь все до последнего сообщения.

или ну худой конец syslog настроить, чтоб на соседний сервер логи отправлял.

мож с железом что не так?

Вряд ли. Гугление говорит о том, что это проблема настроек дефолтовых значений Linux'а. Прошлый раз (когда аптайм был в 37 суток) казалось, что помогло увеличение параметров /sys/block/sda/device/timeout - у Gentoo там по дефолту 15 секунд, а, например, у CentOS - 60.

или ну худой конец syslog настроить, чтоб на соседний сервер логи отправлял.

Если ты про консоль - по KVM видно, что там всё чисто. Иногда вываливается что-то типа такого: http://i042.radikal.ru/0912/03/ff881eadf280.png

Но чаще - девственная консоль, висящая намертво.

Если про dmesg - сработала идея кидать вывод на другую машину по sshfs. Начало процесса выглядит так:

mptscsih: ioc0: attempting task abort! (sc=ffff88022aa2bf00)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 0a 44 5f 2b 00 00 08 00
mptscsih: ioc0: WARNING - TaskMgmt type=1: IOC Not operational (0xffffffff)!
mptscsih: ioc0: WARNING - Issuing HardReset from mptscsih_IssueTaskMgmt!!
mptbase: ioc0: Initiating recovery
mptbase: ioc0: WARNING - Unexpected doorbell active!
mptbase: ioc0: ERROR - Failed to come READY after reset! IocState=f0000000
mptbase: ioc0: WARNING - ResetHistory bit failed to clear!
mptbase: ioc0: ERROR - Diagnostic reset FAILED! (ffffffffh)
mptbase: ioc0: WARNING - NOT READY WARNING!
mptbase: WARNING - (-1) Cannot recover ioc0
mptscsih: ioc0: WARNING - TaskMgmt HardReset FAILED!!
mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022aa2bf00)
mptscsih: ioc0: attempting task abort! (sc=ffff88022aa2bf00)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
mptscsih: ioc0: task abort: FAILED (sc=ffff88022aa2bf00)
mptscsih: ioc0: attempting target reset! (sc=ffff88022aa2bf00)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
mptscsih: ioc0: WARNING - TaskMgmt type=3: IOC Not operational (0xffffffff)!
mptscsih: ioc0: WARNING - Issuing HardReset from mptscsih_IssueTaskMgmt!!
mptbase: ioc0: Initiating recovery
mptbase: ioc0: WARNING - Unexpected doorbell active!
mptbase: ioc0: ERROR - Failed to come READY after reset! IocState=f0000000
mptbase: ioc0: WARNING - ResetHistory bit failed to clear!
mptbase: ioc0: ERROR - Diagnostic reset FAILED! (ffffffffh)
mptbase: ioc0: WARNING - NOT READY WARNING!
mptbase: WARNING - (-1) Cannot recover ioc0
mptscsih: ioc0: WARNING - TaskMgmt HardReset FAILED!!
mptscsih: ioc0: target reset: SUCCESS (sc=ffff88022aa2bf00)
mptscsih: ioc0: attempting task abort! (sc=ffff88022f37c200)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 ff 74 3e 00 00 08 00
mptscsih: ioc0: task abort: FAILED (sc=ffff88022f37c200)
mptscsih: ioc0: attempting task abort! (sc=ffff88022f37cb00)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 ff da de 00 00 08 00
mptscsih: ioc0: task abort: FAILED (sc=ffff88022f37cb00)
mptscsih: ioc0: attempting task abort! (sc=ffff88022f37c400)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 ff db 46 00 00 08 00
mptscsih: ioc0: task abort: FAILED (sc=ffff88022f37c400)
mptscsih: ioc0: attempting task abort! (sc=ffff88021e300900)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 04 01 92 fe 00 00 08 00
mptscsih: ioc0: task abort: FAILED (sc=ffff88021e300900)
...

Но это я и раньше видел.

Дело точно не в винте. Я пробовал всю систему переносить с одного а другой - пофиг. К тому же вылетает иногда сперва sda, за ним - sdb, иногда - наоборот.

Вылетает контроллер.

Нагугливается и по советам техподдержки выходит, что нестыковка где-то в каких-то параметрах заставляет Linux пытаться резетнуть когда он долго не отвечает, разбираясь со своими очередями. Как уже писал выше, раньше считали, что помогло увеличение таймаутов дисков в /sys/block/sda/device/timeout

Увы, похоже, дело было [не только] в этом.

При чём, что интересно, нет корреляции с нагрузкой. Самый первый вылет был на простаивающей, ещё не выведенной в Интернет машине. И под нагрузкой, пиковую нагрузку чаще всего держит без проблем. Вылетает непредсказуемо.

Вот, может, ещё инфа для размышления поможет: http://admin.airbase.ru/munin/

Нагугливается тут совет попробовать iommu=soft в параметрах ядра:

https://bugs.launchpad.net/fedora/+source/linux/+bug/343749

https://bugzilla.redhat.com/show_bug.cgi?id=541615

Насколько сильно это на производительности скажется?

вот оно в dmesg: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Т.е. там итак soft.

Может просто контроллер бракованный? Или перегревается, или дорожки на материнке пробило?

>Может просто контроллер бракованный?

Маловероятно. Перед продажей сервер проходил жёсткое тестирование у поставщика, около суток стресс-тестов.

Или перегревается

Мониторинг (через KVM) говорит, что всё в порядке. Да и вылетает он не коррелируя с нагрузкой и временем работы. Может, вон, 37 дней отработать без проблем, а может вылетать каждые полчаса.

>http://admin.airbase.ru/munin/

Чего то там нету sensors. Может все таки перегрев? :)

А относительно кидать dmesg на sshfs. Вроде же есть klogd или кто там ещё, который настраиватся, что писать в syslogd, который в свою очередь настраиватеся что писать на удалённый сервер, а что на консоль. Может эта связка и выглядит сложнее, но так помимо сообщений ещё есть timestamp, можно отследить, ждал драйвер таймаут или сразу всё зависает.

Попробуйте «echo 1 > /sys/block/sda/device/queue_depth», может поможет...

>И в ту же степь - на что влияет /sys/block/sda/device/queue_depth

АФАИК длинна очереди команд устройству, которую оно будет тасовать по своему усмотрению для достижения лучшей производительности. 0 эквивалентен превращению в обычный IDE винт.

>Чего то там нету sensors

Потому что к ipmi доступ есть только у root'а, а я не хочу munin от root'а запускать :)

Вроде же есть klogd или кто там ещё, который настраиватся, что писать в syslogd, который в свою очередь настраиватеся что писать на удалённый сервер, а что на консоль

Проще dmesg кидать, чем разбираться с этим зоопарком.

Попробуйте «echo 1 > /sys/block/sda/device/queue_depth»

По дефолту было 64, в CentOS (с которым, как говорит саппорт поставщика сервера всё ок) - 256. Виснет и с 256 и с 16 (последняя попытка была). Ну, попробую 1 :)

Рандомные зависания в случайные времена — типичнейши признак глючащего железа. Ты занимаешься поеданием кактусов и все не веришь, что они колятся.

Ладно, завтра запускаем вторую машину с точно таким же сочетанием железа и софта. Посмотрим, что получится :)

Всё, допрыгался. Слетела FS. Придётся переставлять систему.

Хех. Оживил, вручную разобрав lost+found :)

>Проще dmesg кидать, чем разбираться с этим зоопарком.

Проще, но нет даты/времени. Не видно, сколько мс прошло между сообщениями.

Всё, допрыгался.

То есть «echo 1 > /sys/block/sda/device/queue_depth» не помогло? Тогда терять нечего, начнайте сами править ядро, Си то ведь знаете. :) У меня одни знакомый пару месяцев правил ядро, которое висло на сервере (мамка Intel, RAID Intel SRCS14). Потом заявил, что контроллер глючный. А потом там спокойно заработала CentOS.

>То есть «echo 1 > /sys/block/sda/device/queue_depth» не помогло?

Вылетело ещё на 16. Потом поставил 1, но с ним уже дважды вылетало.

А потом там спокойно заработала CentOS.

Вот мне тоже в техподдержке сказали, что с CentOS они работу сервера гарантируют :)

Ну, думаю, что можно попробовать загрузить gentoo с ядром от СеntOS. Ядро за собой особо ничего не потянет, ну может iptables другой. Наверное, даже можно sysctl не трогать. И производительность, подобный изыск, не должен сильно изменить, все таки не Кербеос или ЛДАП. Конечно, если проблемы продолжется, то техподдержка откорячется, что это не CentOS, но хотя бы станет ясно, что и CentOS там не заработает...

На неделе попробую, что ли :)

...

Пока поставил авторестарт и авторепейр падучих БД. Плюс дамп-бэкап их каждые 6 часов. Вот, в 8 часов опять перезагружалось.