"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, соответственно)

KRoN73 (12.12.2009 5:53:55)

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

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

sergej (12.12.2009 12:29:19)

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

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

KRoN73 (12.12.2009 14:19:12)

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

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

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

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

...

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

...

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

KRoN73 (12.12.2009 15:04:29)

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

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

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

sergej (12.12.2009 17:04:38)

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

Вряд ли. Гугление говорит о том, что это проблема настроек дефолтовых значений 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/

KRoN73 (12.12.2009 18:06:20)

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

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

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

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

KRoN73 (12.12.2009 18:16:39)

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

KRoN73 (12.12.2009 18:29:35)

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

annoynimous (12.12.2009 18:38:04)

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

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

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

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

KRoN73 (12.12.2009 18:40:38)

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

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

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

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

mky (12.12.2009 21:02:35)

>И в ту же степь - на что влияет /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 :)

KRoN73 (12.12.2009 22:58:06)

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

annoynimous (12.12.2009 23:26:54)

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

KRoN73 (12.12.2009 23:28:56)

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

KRoN73 (13.12.2009 5:52:26)

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

KRoN73 (13.12.2009 8:16:08)

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

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

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

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

mky (13.12.2009 10:28:51)

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

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

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

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

KRoN73 (13.12.2009 13:53:55)

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

mky (13.12.2009 22:02:02)

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

...

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

KRoN73 (13.12.2009 22:22:30)