LINUX.ORG.RU

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


0

0

Опять начал зависать сервер. 37 суток без единого нарекания отработал и снова стал валиться в kernel panic несколько раз в день.

В dmesg иногда удаётся отловить:

mptscsih: ioc0: attempting task abort! (sc=ffff88022eadaf00)
sd 4:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 04 d8 eb 06 00 00 28 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!
INFO: task pdflush:267 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
pdflush       D ffff880164968d90     0   267      2 0x00000000
 ffff88022ea13650 0000000000000046 ffffffff810824f1 00011220ffffffff
 ffff8801784104d0 0000000000010c80 000000000000c8e8 ffff88022f8bf080
 ffff88022e76c4c0 ffff88022f8bf320 000000012ea135f0 0000000000000002
Call Trace:
 [<ffffffff810824f1>] ? 0xffffffff810824f1
 [<ffffffff81147ba1>] ? 0xffffffff81147ba1
 [<ffffffff810548c2>] ? 0xffffffff810548c2
 [<ffffffff81148e15>] 0xffffffff81148e15
 [<ffffffff81054a10>] ? 0xffffffff81054a10
 [<ffffffff8113d906>] ? 0xffffffff8113d906
 [<ffffffff81148f9c>] 0xffffffff81148f9c
 [<ffffffff8113aec7>] 0xffffffff8113aec7
 [<ffffffff8113fdaa>] 0xffffffff8113fdaa
 [<ffffffff81142d55>] 0xffffffff81142d55
 [<ffffffff81138786>] ? 0xffffffff81138786
 [<ffffffff8113a1a2>] 0xffffffff8113a1a2
 [<ffffffff81192294>] ? 0xffffffff81192294
 [<ffffffff8138b30c>] ? 0xffffffff8138b30c
 [<ffffffff8138b3dc>] ? 0xffffffff8138b3dc
 [<ffffffff81125519>] 0xffffffff81125519
 [<ffffffff8108920e>] ? 0xffffffff8108920e
 [<ffffffff81125a05>] 0xffffffff81125a05
 [<ffffffff81088d32>] ? 0xffffffff81088d32
 [<ffffffff81086fc1>] ? 0xffffffff81086fc1
 [<ffffffff81126670>] ? 0xffffffff81126670
 [<ffffffff811263fd>] 0xffffffff811263fd
 [<ffffffff810548df>] ? 0xffffffff810548df
 [<ffffffff81087348>] 0xffffffff81087348
 [<ffffffff810ca6eb>] 0xffffffff810ca6eb
 [<ffffffff810345ca>] ? 0xffffffff810345ca
 [<ffffffff811a3eb0>] ? 0xffffffff811a3eb0
 [<ffffffff810caeb1>] 0xffffffff810caeb1
 [<ffffffff810cb16e>] 0xffffffff810cb16e
 [<ffffffff810874fc>] 0xffffffff810874fc
 [<ffffffff81088240>] ? 0xffffffff81088240
 [<ffffffff81088346>] 0xffffffff81088346
 [<ffffffff81087440>] ? 0xffffffff81087440
 [<ffffffff81054616>] 0xffffffff81054616
 [<ffffffff8100cd7a>] 0xffffffff8100cd7a
 [<ffffffff81054570>] ? 0xffffffff81054570
 [<ffffffff8100cd70>] ? 0xffffffff8100cd70
INFO: task lighttpd:26588 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
lighttpd      D ffff88012e411ca8     0 26588  26426 0x00000000
 ffff88012e411c18 0000000000000086 ffff88012e411b68 ffffffff811a5817
 ffff88017f5a0600 0000000000010c80 000000000000c8e8 ffff8801cd0fddc0
 ffff88018ad23e80 ffff8801cd0fe060 000000002f604000 ffff88022e580120
Call Trace:
 [<ffffffff811a5817>] ? 0xffffffff811a5817
 [<ffffffff8105c3cc>] ? 0xffffffff8105c3cc
 [<ffffffff813896b3>] 0xffffffff813896b3
 [<ffffffff810801ad>] 0xffffffff810801ad
 [<ffffffff81389a52>] 0xffffffff81389a52
 [<ffffffff81080180>] ? 0xffffffff81080180
 [<ffffffff81080164>] 0xffffffff81080164
 [<ffffffff81054a10>] ? 0xffffffff81054a10
 [<ffffffff8107ff8b>] ? 0xffffffff8107ff8b
 [<ffffffff810802e8>] 0xffffffff810802e8
 [<ffffffff81080937>] 0xffffffff81080937
 [<ffffffff810861a7>] ? 0xffffffff810861a7
 [<ffffffff81093973>] 0xffffffff81093973
 [<ffffffff810955d9>] 0xffffffff810955d9
 [<ffffffff8102b14f>] 0xffffffff8102b14f
 [<ffffffff8138ba6f>] 0xffffffff8138ba6f
INFO: task lighttpd:26590 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
lighttpd      D ffff88020c581b18     0 26590  26426 0x00000000
 ffff88020c581a88 0000000000000082 ffff88020c5819d8 ffffffff811a5817
 ffff88022eadaf00 0000000000010c80 000000000000c8e8 ffff8801cd0f9900
 ffff8801cd0fcb00 ffff8801cd0f9ba0 0000000200000038 ffff88022e580120
Call Trace:
 [<ffffffff811a5817>] ? 0xffffffff811a5817
 [<ffffffff8105c3cc>] ? 0xffffffff8105c3cc
 [<ffffffff813896b3>] 0xffffffff813896b3
 [<ffffffff810801ad>] 0xffffffff810801ad
 [<ffffffff81389a52>] 0xffffffff81389a52
 [<ffffffff81080180>] ? 0xffffffff81080180
 [<ffffffff81080164>] 0xffffffff81080164
 [<ffffffff81054a10>] ? 0xffffffff81054a10
 [<ffffffff8107ff8b>] ? 0xffffffff8107ff8b
 [<ffffffff810ce5c7>] 0xffffffff810ce5c7
 [<ffffffff810bf4a1>] ? 0xffffffff810bf4a1
 [<ffffffff810b475f>] ? 0xffffffff810b475f
 [<ffffffff810bde8c>] ? 0xffffffff810bde8c
 [<ffffffff812e6a60>] ? 0xffffffff812e6a60
 [<ffffffff810c4d54>] ? 0xffffffff810c4d54
 [<ffffffff810cd0e0>] ? 0xffffffff810cd0e0
 [<ffffffff810ce789>] 0xffffffff810ce789
 [<ffffffff810cc9f7>] 0xffffffff810cc9f7
 [<ffffffff810cd2fc>] 0xffffffff810cd2fc
 [<ffffffff810cc960>] ? 0xffffffff810cc960
 [<ffffffff810cd442>] 0xffffffff810cd442
 [<ffffffff810aba17>] 0xffffffff810aba17
 [<ffffffff810abb25>] 0xffffffff810abb25
 [<ffffffff810b9e18>] ? 0xffffffff810b9e18
 [<ffffffff8100bd6b>] 0xffffffff8100bd6b

Так вот, интересно:

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

оно просто уберёт сообщение, но система продолжит виснуть? :) А если дефолтовые тамошние 120 сек. наоборот увеличить?

За что, вообще, этот параметр отвечает? Не нагугливается что-то...

★★★★★

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

KRoN73 ★★★★★ ()

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

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

sergej ★★★★★ ()
Ответ на: комментарий от sergej

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от ucalculus

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

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

...

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

...

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

sergej ★★★★★ ()
Ответ на: комментарий от sergej

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от annoynimous

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

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

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


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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

mky ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от mky

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

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

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


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

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


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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

annoynimous ★★★★★ ()
Ответ на: комментарий от annoynimous

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

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


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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

...

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

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.