LINUX.ORG.RU
решено ФорумAdmin

INFO: task <task>:<id> blocked for more than 120 seconds. Часть 2.


1

2

Продолжение марлезонского балета.

В общем, решено было записать gentoo livecd и прогнать самописным тестом:

#!/bin/bash

while true; do
echo "$(date -R | awk '{print $2,$3,$5}')   Test CPU, HDD (dd + urandom, 128M, 256M, 512M, 1G)" >> /mnt/debian/var/log/testserver.log
`dd if=/dev/urandom of=/mnt/debian/tmp/testfile128M.img bs=1k count=131072 2>/dev/null; echo "$(date -R | awk '{print $2,$3,$5}')   Test dd 128M finished" >> /mnt/debian/var/log/testserver.log` &
`dd if=/dev/urandom of=/mnt/debian/tmp/testfile256M.img bs=1k count=262144 2>/dev/null; echo "$(date -R | awk '{print $2,$3,$5}')   Test dd 256M finished" >> /mnt/debian/var/log/testserver.log` &
`dd if=/dev/urandom of=/mnt/debian/tmp/testfile512M.img bs=1k count=524288 2>/dev/null; echo "$(date -R | awk '{print $2,$3,$5}')   Test dd 512M finished" >> /mnt/debian/var/log/testserver.log` &
`dd if=/dev/urandom of=/mnt/debian/tmp/testfile1G.img bs=1k count=1048576 2>/dev/null; echo "$(date -R | awk '{print $2,$3,$5}')   Test dd 1G finished" >> /mnt/debian/var/log/testserver.log`
rm -rf /mnt/debian/tmp/testfile*
echo "$(date -R | awk '{print $2,$3,$5}')   Test CPU, HDD (dd, urandom) finished" >> /mnt/debian/var/log/testserver.log
sleep 60
echo "$(date -R | awk '{print $2,$3,$5}')   Test memory (copy in tmpfs)" >> /mnt/debian/var/log/testserver.log
cp /mnt/debian/root/iso-* /mem/
echo "$(date -R | awk '{print $2,$3,$5}')   Test memory: copying files finished" >> /mnt/debian/var/log/testserver.log
sleep 120
echo "$(date -R | awk '{print $2,$3,$5}')   Test memory: finished. Copying files not deleted" >> /mnt/debian/var/log/testserver.log
echo "$(date -R | awk '{print $2,$3,$5}')   Test HDD (dd + /dev/zero, 10G)" >> /mnt/debian/var/log/testserver.log
dd if=/dev/zero of=/mnt/debian/tmp/testfile10G.img bs=1k count=10485760 2>/dev/null
echo "$(date -R | awk '{print $2,$3,$5}')   Test HDD (dd + /dev/zero, 10G), finished" >> /mnt/debian/var/log/testserver.log
rm -rf /mnt/debian/tmp/testfile*
rm -rf /mem/iso-*
sleep 120
done

До этого я трижды прогонял этот тест (на Debiane, который был установлен на этом рейде), и дважды сервак вис после «Test dd 512M finished».

Теперь, я получил возможность срисовать логи, итак, грузимся, монтируемся:

...
Jan 23 12:26:26 livecd kernel: EXT4-fs (cciss!c0d0p1): mounted filesystem with ordered data mode. Opts: (null)
Jan 23 12:27:14 livecd dhcpcd[24180]: enp3s1f1: broadcasting for a lease
Jan 23 12:27:15 livecd dhcpcd[24180]: enp3s1f0: broadcasting for a lease
...

Спустя 2,5 суток, упс!

...
Jan 25 20:24:47 livecd kernel: INFO: task jbd2/cciss!c0d0:24327 blocked for more than 120 seconds.
Jan 25 20:24:47 livecd kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 25 20:24:47 livecd kernel: jbd2/cciss!c0d0 D f6788000     0 24327      2 0x00000000
Jan 25 20:24:47 livecd kernel: f3c23b10 00000046 1b54d000 f6788000 f6c59770 0a646588 00024a73 c155ef80
Jan 25 20:24:47 livecd kernel: c155ef80 c14d2140 f6febcd8 c1045fb5 f6febce8 f6febce8 00000202 00000202
Jan 25 20:24:47 livecd kernel: c10591d9 3b4d88fb 00000007 0a6476d8 00024a73 f6febcc8 0266a950 c14d2140
Jan 25 20:24:47 livecd kernel: Call Trace:
Jan 25 20:24:47 livecd kernel: [<c1045fb5>] ? ktime_get_ts+0x41/0xc6
Jan 25 20:24:47 livecd kernel: [<c10591d9>] ? delayacct_end+0x8d/0x95
Jan 25 20:24:47 livecd kernel: [<c10a24e6>] ? __wait_on_buffer+0x1a/0x1a
Jan 25 20:24:47 livecd kernel: [<c1045fb5>] ? ktime_get_ts+0x41/0xc6
Jan 25 20:24:47 livecd kernel: [<c10a24e6>] ? __wait_on_buffer+0x1a/0x1a
Jan 25 20:24:47 livecd kernel: [<c1398533>] ? io_schedule+0x6e/0xa2
Jan 25 20:24:47 livecd kernel: [<c10a24eb>] ? sleep_on_buffer+0x5/0x8
Jan 25 20:24:47 livecd kernel: [<c1397150>] ? __wait_on_bit+0x2d/0x58
Jan 25 20:24:47 livecd kernel: [<c13971d6>] ? out_of_line_wait_on_bit+0x5b/0x63
Jan 25 20:24:47 livecd kernel: [<c10a24e6>] ? __wait_on_buffer+0x1a/0x1a
Jan 25 20:24:47 livecd kernel: [<c1036f3a>] ? autoremove_wake_function+0x29/0x29
Jan 25 20:24:47 livecd kernel: [<c10a24e4>] ? __wait_on_buffer+0x18/0x1a
Jan 25 20:24:47 livecd kernel: [<c113739a>] ? jbd2_journal_commit_transaction+0xaa5/0x1077
Jan 25 20:24:47 livecd kernel: [<c113971c>] ? kjournald2+0xa3/0x1ac
Jan 25 20:24:47 livecd kernel: [<c113971c>] ? kjournald2+0xa3/0x1ac
Jan 25 20:24:47 livecd kernel: [<c1036f11>] ? abort_exclusive_wait+0x63/0x63
Jan 25 20:24:47 livecd kernel: [<c1139679>] ? commit_timeout+0x5/0x5
Jan 25 20:24:47 livecd kernel: [<c103686b>] ? kthread+0x8d/0x92
Jan 25 20:24:47 livecd kernel: [<c13997bb>] ? ret_from_kernel_thread+0x1b/0x30
Jan 25 20:24:47 livecd kernel: [<c10367de>] ? __kthread_parkme+0x50/0x50
...

Вот лог при попытке писать процессом test.sh:

...
Jan 25 20:26:47 livecd kernel: INFO: task test.sh:28913 blocked for more than 120 seconds.
Jan 25 20:26:47 livecd kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 25 20:26:47 livecd kernel: test.sh         D 00000001     0 28913  24246 0x00000000
Jan 25 20:26:47 livecd kernel: f654bb10 00000086 ffffffff 00000001 f6c59030 c78d2438 c3ef4358 c155ef80
Jan 25 20:26:47 livecd kernel: c155ef80 f6a0b6a0 db44c588 db44c5c0 00001000 f533f780 f685f320 f31e9000
Jan 25 20:26:47 livecd kernel: c10a4620 00001000 00000001 f7548760 c155ef80 00000246 00000246 c1036e16
Jan 25 20:26:47 livecd kernel: Call Trace:
Jan 25 20:26:47 livecd kernel: [<c10a4620>] ? __getblk+0x23/0x283
Jan 25 20:26:47 livecd kernel: [<c1036e16>] ? prepare_to_wait+0x57/0x5f
Jan 25 20:26:47 livecd kernel: [<c11361d4>] ? do_get_write_access+0x1ae/0x346
Jan 25 20:26:47 livecd kernel: [<c1036f3a>] ? autoremove_wake_function+0x29/0x29
Jan 25 20:26:47 livecd kernel: [<c113644f>] ? jbd2_journal_get_write_access+0x18/0x26
Jan 25 20:26:47 livecd kernel: [<c111eb42>] ? __ext4_journal_get_write_access+0x3b/0x4e
Jan 25 20:26:47 livecd kernel: [<c11086a0>] ? ext4_reserve_inode_write+0x2c/0x5f
Jan 25 20:26:47 livecd kernel: [<c11086f2>] ? ext4_mark_inode_dirty+0x1f/0x14f
Jan 25 20:26:47 livecd kernel: [<c110aeba>] ? ext4_dirty_inode+0x2c/0x42
Jan 25 20:26:47 livecd kernel: [<c109df06>] ? __mark_inode_dirty+0x1e/0x185
Jan 25 20:26:47 livecd kernel: [<c1095d8b>] ? update_time+0x81/0x8a
Jan 25 20:26:47 livecd kernel: [<c1095e05>] ? file_update_time+0x71/0x8a
Jan 25 20:26:47 livecd kernel: [<c1063364>] ? __generic_file_aio_write+0x239/0x3a0
Jan 25 20:26:47 livecd kernel: [<c106351f>] ? generic_file_aio_write+0x54/0x9a
Jan 25 20:26:47 livecd kernel: [<c1103089>] ? ext4_file_write+0x3ec/0x413
Jan 25 20:26:47 livecd kernel: [<c108d348>] ? link_path_walk+0x57/0x675
Jan 25 20:26:47 livecd kernel: [<c1075289>] ? do_wp_page+0x2b6/0x641
Jan 25 20:26:47 livecd kernel: [<c108f884>] ? path_openat.isra.57+0x9c/0x33a
Jan 25 20:26:47 livecd kernel: [<c1076c32>] ? handle_pte_fault+0x5f6/0x633
Jan 25 20:26:47 livecd kernel: [<c108574d>] ? do_sync_write+0x61/0x88
Jan 25 20:26:47 livecd kernel: [<c10856ec>] ? do_sync_readv_writev+0x8d/0x8d
Jan 25 20:26:47 livecd kernel: [<c1085fa6>] ? vfs_write+0x9d/0x13d
Jan 25 20:26:47 livecd kernel: [<c10862ad>] ? SyS_write+0x3f/0x6c
Jan 25 20:26:47 livecd kernel: [<c1398ff8>] ? syscall_call+0x7/0xb
...

Итого: баг проявляется на разных винтах, т.е. это не проблема бэдов. Получается гайка контроллеру/материнке?

Решено обновлением прошивки

★★★★★

Последнее исправление: leg0las (всего исправлений: 1)

Ответ на: комментарий от leg0las

Ничего сложного, записываешь HP Smart Update Firmware DVD 9.10С (это последняя версия, поддерживающая G4) или более ранний, если нужно обновление биоса, и обновляешья с него.

waster
()
Ответ на: комментарий от leg0las

На hp.com для G4 есть и 9.10С. И там явно написано:

The following HP ProLiant servers will have baselined firmware support on
the Smart Update Firmware
DVD 9.10. Firmware support for these servers will be removed in the following version of the Smart
Update Firmware DVD
...
HP ProLiant DL380 G4 Server
...

Я с него грузился и далее выбирал в интерактивном режиме Firmware Update. В принципе там все интуитивно понятно.

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

Да, я уже увидел в документации на диске к 9.30, что там DL380 G5-G7 (grep`ом глянул)

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

Ты на диск записывал или старым добрым dd образ на флешку? А то с флешки не хочет грузится ни в какую.

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

dd'хой загрузочную флешку из этого образа не получится, не тот образ, надо использовать HP USB Key Utility для этого. Или можно на диск записать.

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

Т.е. можно просто на диск DVD-диск залить и загрузится?

И как использовать USB Key utility, а то там в скрипте я видел только копирование файлов по шаблону.

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

Да, можно просто на диск. Ну а объяснять как использовать виндовую утилиту, в которой делается все по шагам элементарно, думаю, нет смысла.

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

Понял, благодарю. В пнд прихвачу диск.

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

Прошивку обновил, вместо 2.32/2.34 стала 2.84. Запустил тесты, ждем-с.

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

PS если не ошибаюсь, лет пять-семь назад мы юзали парочку этих proliant 380 G4 в ДЦ лизвеба. Короче, говнище полное.

Надеюсь, не с убунтой? Официально они поддерживают rhel. Ну значит и centos с ораклос будет работать без проблем.

Я как-то по запросу клиента установил убунту на g8. Понял что не хочет там убунта работать.

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

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

А тестировать сверхновые 3.11 в продуктиве никто в здравом уме не будет.

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

Надеюсь, не с убунтой?

С убунтой и gentoo. RHEL/centos/etc по условию задачи не подходили.

Официально они поддерживают rhel

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

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

А мне новые ядра и не нужны, там 2.6.32 отлично вертелось, и 3.2 тоже ничего.

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

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

Удваиваю.

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

А разве ilo там нет? Подключаешься удалённо, и удалённо же обновляешь.

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

И заодно посмотри, нет ли в ilo информации о проблемах с железом. И со стороны оси можно запустить

hpacucli ctrl all show config
hpacucli ctrl all show config detail | egrep '(cache|batt)'
router ★★★★★
()
Ответ на: комментарий от true_admin

Честно говоря, для меня официальная поддержка пустой звук

А для меня - отсутствие геморроя. Только hp и ibm, только rhel - и никаких проблем с железом, пока железо физически не выйдет из строя. И 12309 видел только дома :)

Если ОСь и сервер на поддержке, то при таких странных глюках можно завести тикет, и они сами будут разбираться, менять неисправные части и писать обновление прошивки. А в случае неподдерживаемой ОСи просто пошлют лесом. Вежливо и с предложением установить поддерживаемую ОСь.

Опять же, для поддерживаемых ОСей есть родные утилиты для работы с железом

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

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

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

Я даже не в курсе, есть ли оно там, надо будет посмотреть теперь. Тулзовину гляну.

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

Только hp

никаких проблем с железом

На этих 380 была массовая проблема с ILO — они спустя пару-тройку недель работы вешались до следующего ребута. У вендора ушло больше трёх месяцев на исправление проблемы. Мне такой саппорт даром не нужен.

А в случае неподдерживаемой ОСи просто пошлют лесом.

Ради бога. Уже лет 10 как-то обхожусь без саппорта со стороны вендоров и ещё столько же обойдусь.

Когда серверов несколько десятков или сотен

Вот только давай не будем меряться у кого больше. К слову, если серваки однотипные то пусть их хоть тыща — средства автоматизации решают.

тру следование заветам Столлмана.

Столлман тут ни при чём. Поддержка в ваниле это хоть какая-то гарантия того что через пару лет можно будет водрузить свежую ось. Знаешь сколько я видел железа которое rhel4 only? Мне такое даром не нужно.

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

На этих 380 была массовая проблема с ILO — они спустя пару-тройку недель работы вешались до следующего ребута. У вендора ушло больше трёх месяцев на исправление проблемы. Мне такой саппорт даром не нужен.

Не застал. Со стороны ОСи тоже нельзя было перезагрузить через hponcfg ?

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

Вот только давай не будем меряться у кого больше. К слову, если серваки однотипные то пусть их хоть тыща — средства автоматизации решают.

Верю, что у тебя и длиннее, и толще ;) Но привык к лёгкости диагностики. Не нужно думать о том «а что бы ещё вывести в систему мониторинга» - если есть проблема с железом - она отражается в ilo, и в систему мониторинга забираю общий статус ilo. Проблемы с сервером диагностируются на уровне самого сервера, а не ОСи, их не пропустишь.

Я пользуюсь и puppet, и cfengine. На мой взгляд, у них несколько другие задачи

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

Со стороны ОСи тоже нельзя было перезагрузить через hponcfg ?

Я не пробовал (и, честно говоря, об этой команде не знал). Этим вопросом плотно занимались leaseweb. Они сказали что HP о проблеме знает и они работают над новой прошивкой. Мы их пинали, они нам может даже форвардили ответы от поддержки... Но, в основном, всё сводилось к тому что «проблема массовая, замена железа не помогает, как лечить пока непонятно».

Но мысль ты высказал верную — на вендора надейся, а сам не плошай. Я же об этом и говорю — когда речь идёт о простое популярного сайта каждая минута это потерянные деньги. Для нас было дешевле арендовать новый сервер, залить всё туда, а старый тупо отдать хостеру. Это самое быстрое решение проблемы.

Вот это и есть моя философия — время развёртования системы должно быть как можно меньше чтобы не быть привязанным к каким-то конкретным железкам.

Я, кстати, готов на эту тему предметно поговорить. Мне это интересно.

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

Верю, что у тебя и длиннее, и толще

Неа, я работал на дедиках, у нас там были, в основном, проекты которые целиком влезали на один сервер. Больших проектов практически не было.

А самая моя большая гордость этот тот проект под который и была отведена та тачка от HP. Там была адская посещаемость, нас было два сисадмина и три программиста и мы проект адски тюнили потому что надо было вложиться в бюджет по железу и трафику (если проект себя не окупает то он никому не нужен). Поэтому и перешли на gentoo, патчи для мускля от перконы итд итп. Вот там хорошо пришлось поковыряться и в драйверах ОС, и в кишках php c APC, и баги в pecl-овских библиотеках выискивать... А всё потому что по сравнению с, скажем, rhel5 наше решение работало чуть ли не в два раза быстрее.

Казалось бы, ну, подумаешь, ещё один сервер поставить, что такого? Только так просто система не масштабировалась. В моё время этот вопрос решили раcпилом сайта на отдельные «сервисы»: БД отдельно, статика отдельно, php отдельно. Потом ещё надо было отказоустойчивость поверх этого намутить. Плюс, мы арендовали стойку, а место в стойке ограничено, как и питание. Нужно было все вопросы решать с учётом этих ограничений.

Вот, примерно на таких проектах я работал :)

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

если есть проблема с железом - она отражается в ilo

На той платформе, кстати, два сервера поменяли потому что там прямо «на горячую» отваливался один проц. Т.е. сервак зависал, его ребутали и он поднимался без одного проца. Т.е. не все проблемы дают о себе знать заранее.

true_admin ★★★★★
()

Перепрошил. Сервер под тестами проработал 4+ суток (больше 2-2,5 до перепрошивки не работал), сейчас раскатываю потихоньку назад ПО, паралельно смотря в dmesg и глядя на uptime. Проблема таки действительно пропала.

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