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)

Ты весь dmesg-то покажи.

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

true_admin ★★★★★
()

Да, кстати, 12309 проявлялся именно так. И именно на этой платформе. Так что, возможно, железо тут ни при чём.

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

Ты весь dmesg-то покажи.

в dmesg пусто (после загрузки), это /var/log/messages.

Там то смотреть нечего, там бут (то, что я привел, где инициализируется раздел), потом несколько сообщений сислога:

Jan 24 00:25:28 livecd syslog-ng[23619]: Log statistics; processed='center(received)=12', processed='center(queued)=1522', processed='source(src)=12', processed='destination(console_all)=761', processed='destination(messages)=761', processed='global(payload_reallocs)=34', processed='global(sdata_updates)=11', processed='global(msg_clones)=0', processed='src.internal(src#2)=12', stamp='src.internal(src#2)=1390519529'
Jan 24 12:25:28 livecd syslog-ng[23619]: Log statistics; processed='center(received)=24', processed='center(queued)=1546', processed='source(src)=24', processed='destination(console_all)=773', processed='destination(messages)=773', processed='global(payload_reallocs)=36', processed='global(sdata_updates)=11', processed='global(msg_clones)=0', processed='src.internal(src#2)=24', stamp='src.internal(src#2)=1390562729'
Jan 25 00:25:28 livecd syslog-ng[23619]: Log statistics; processed='center(received)=36', processed='center(queued)=1570', processed='source(src)=36', processed='destination(console_all)=785', processed='destination(messages)=785', processed='global(payload_reallocs)=38', processed='global(sdata_updates)=11', processed='global(msg_clones)=0', processed='src.internal(src#2)=36', stamp='src.internal(src#2)=1390605929'
Jan 25 12:25:28 livecd syslog-ng[23619]: Log statistics; processed='center(received)=48', processed='center(queued)=1594', processed='source(src)=48', processed='destination(console_all)=797', processed='destination(messages)=797', processed='global(payload_reallocs)=40', processed='global(sdata_updates)=11', processed='global(msg_clones)=0', processed='src.internal(src#2)=48', stamp='src.internal(src#2)=1390649129'

И потом собственно то, что я написал. Тебе целиком сбросить?

Да, кстати, 12309 проявлялся именно так. И именно на этой платформе

За 2 с небольшим года времени моей работы подобного ни разу не было. Как на 2.6.32, так и на 3.2, до недавнего времени естественно. Да и повторение на разных дистрибутивах наталкивает на мысль, что это железо.

proliant 380 G4 в ДЦ лизвеба. Короче, говнище полное

Заметано. Что посоветуешь на замену?

leg0las ★★★★★
() автор топика
Последнее исправление: leg0las (всего исправлений: 3)
Ответ на: комментарий от leg0las

в dmesg пусто

В смысле нет ничего подозрительного? Ну тогда это точно 12309.

до недавнего времени естественно.

Просто у вас возрасла нагрузка выше некоторого порогового значения. Я тебе даже скажу как воспроизвести проблему. В одной консоли запускаешь dd if=/dev/zero of=/home/verybigfile bs=1M, в другой через пару секунд набираешь sync и всё. Ну, для верности можно vm.dirty_* подтюнить.

Что посоветуешь на замену?

Увы, я в этом не спец. Своих проектов нет, работаю на чужих проектах на том что есть. cast tazhate

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

Не, у нас своя тачка. Ок, попробую воспроизвести)

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

Просто у вас возрасла нагрузка выше некоторого порогового значения

Даже на сервер, на котором НИЧЕГО нет?

У нас летом была нереальная нагрузка - за 14 часов было овер 50к посещений - и ничего не падало.

leg0las ★★★★★
() автор топика
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от leg0las

Посмотри atop или top на предмет нагрузки на IO. Если винты сильно загружены то значит проблема в этом.

PS так ты попробовал мой рецепт подвесить сервер с dd и sync?

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

Еще нет. попробую либо сегодня, либо завтра, отпишусь сюда.

leg0las ★★★★★
() автор топика

Похоже на глюки hp smart array, у тебя явно виснет контроллер и из-за него залипает ядро. Соответсвенно, пишуший процесс туда тоже залипает.

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

Да, было что-то похожее на пролиантах г5 со смарт эррэй 400 или 800, точно уже не помню. Но у тебя явно источник тупняка - драйвер cciss, а что тому причина надо искать...

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

Собственно еще важный момент - на самих винтах постоянно горит красный индикатор, что винт типа не в рейде, хотя на самом деле он в нем.

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

Контроллер/мать помирает. Им 9 лет уже.
Выкидывай нахрен. Пациенту временами может становиться лучше, но это агония.
Если совсем никак - меняй шлейфы, БП, продуй пыль. Но это если эффект и даст то ненадолго.

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

да, дрова контроллера тоже могут быть, но тут тебе самому должно быть видней - апдейты были или нет, не видел чтобы на ровном месте они сыпались. Хотя проприоритарщина, х её з. Имхо скорее все-таки железо, у меня обычно примерно так старички на покой и уходили.

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

Да сейчас оно крутится на дисках, которые ни разу не юзались. Хочешь сказать что все винты решили дружно отдать концы, что даже RAID 1 не спасает?

Оно кстати тогда в dmesg сыпет, что рейд деградированый, или что-то вроде того, только этих ошибок в dmesg нет.

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

я ничего не хочу сказать. Если по отдельности: 1.диски которые не разу не юзались - не факт что нормальные, mhdd тебе в руки, ты сам видел dd вываливается только на >512M, бывает что диск отваливается и при бОльших порогах (полдиска-в порядке, потом резко/вяло/как попало отруб), особенно если учесть что у тебя SCSI а не SAS, сколько эти диски на складе могли валяться ? 2.рейд1 хором, особенно на одновременно поставленных дисках (особенно из одной партии) дохнет в полном объеме только в путь. 3. у 10 рейда есть два варианта сбора, что там у тебя контроллер собирает, я хз, тем более на зная одинаковые ли диски 4. железяка, с которой нет данных в dmesg, почему бы и нет, ну зависла и не отвечает по шине - что увидим ? - примерно то что у тебя и будет 5. мать/контроллер с умирающими и не вздутыми кондеями - норма, особенно при таком возрасте железа 6. сложение любых из предыдущих пунктов - через раз 7. Сервер с 10 рейдом, гигом оперативы - что-то невнятное, или своп (прощай скорость 10) или я хз чем его занять без свопа (роутеру вроде рейд 10 не нужен :) ) 8. предыдущий админ не осиливший LVM, особенно если использовал mdadm, вполне мог быть прав, чуя проблемы с железом - собирай потом данные совочком. 9.заказчик который считает что железо вечное - ну и хер с ним, с заказчиком из сказать у меня есть только одно - хватит насиловать труп

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

ну зависла и не отвечает по шине - что увидим ?

Сообщения от драйвера что железка зависла и ей послан резет.

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

Он будет гадить в dmesg, инфа 100% из drivers/block/cciss*.c

Так что в первую очередь сейчас надо смотреть top, iostat итп.

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

В одной консоли запускаешь dd if=/dev/zero of=/home/verybigfile bs=1M, в другой через пару секунд набираешь sync и всё

Итак, наконец добрался я до сервера. Сделал, (liveusb gentoo) sync отработал безупречно раз 7-8, dmesg кристально чист на предмет варнингов и эрроров.

Зато установщик дебиана сыпал в dmesg cciss ... i/o error.

Фоточки будут вечером, когда домой приду.

leg0las ★★★★★
() автор топика
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от true_admin

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

Фотки не выложил, постараюсь сегодня.

leg0las ★★★★★
() автор топика
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от leg0las

Дык проблема в том что если происходит sync то все процессы что пишут на диск подвисают. Поэтому вхолостую гонять dd и sync нет смысла.

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

На одной консоле запускаешь dd, на второй через секунд sync (главное, чтобы был превышен порог vm.dirty_ratio), а на третей, скажем, mc или другую тулзу которая хоть что-пишет на диск. Если моя теория верна, то mc будет дико лагать при запуске.

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

Сделал в общем, на работающей системе (Debian).

# dd if=/dev/zero of=/var/tmp/bigfile.img

В другой консоли делаю sync, в третей запущен mc. sync проходит настолько быстро, что я даже не успеваю толком переключится на третью консоль, чтобы проверить наличие тормозов в mc.

Вывод (какой я делаю) - не 12309.

Сейчас выложу фотки.

leg0las ★★★★★
() автор топика

На свежем ядре dmesg не советует обновить прошивку контроллера?

Вроде как корень вашей проблемы в непрерывном обращении к разным секторам, чтобы у контроллера не было времени на передышку, одним dd её не спровацировать, запускайте несколько dd одновременно или мучайте диск с помощью fio, вроде как такая команда должна давать ругань про блокированный таск:

fio -readonly -name iops -rw=randread -bs=512 -runtime=300 -iodepth 24 -filename /dev/cciss/c0d0 -ioengine libaio -direct=1

Я правильно понял, что раньше это железо работало на другом (древнем 2.6.x) ядре стабильно?

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

Собственно в тесте запускается 4 dd, чтобы на каждом ядре были (2 2-х головых ксеона).

Железо работало отлично на 2.6.32, и какое-то время на 3.2. Я не помню, когда делал апгрейд с squeeze на wheezy, но точно, что проблема проявилась не сразу.

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

sync проходит настолько быстро, что я даже не успеваю толком переключится на третью консоль

А ты sysctl никакие не крутил? Так быть по-дефолту не должно потому что у тачки много оперативы и dd сначала «пишет в неё» (называется page cache). Когда ты делаешь sync он эти страницы сбрасывает.

Ну и лучше dd вызывать с bs=1M

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

Пардон, ошибся. с bs я вызывал с livecd. Только что сделал

dd if=/dev/zero of=/var/tmp/bigfile.img bs=1M

и sync на другой консоли. секунд 5 оно думало. На третей консоли mc - не тормозит, не лагает, в dmesg ошибок нет.

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

leg0las ★★★★★
() автор топика
Последнее исправление: leg0las (всего исправлений: 1)
Ответ на: комментарий от true_admin

Нет, всегда был 1 гиг. Сервер старый, да и хватало этого гига.

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

Такая же проблема с висом и без каких либо сообщений в логах ж4, причем до апдейта со Squeeze во Wheezy такого не было. Тоже подозреваю, что железо, так как один сказевый контроллер на ж4 у меня уже помирал, на других ж4 с таким же железом Wheezy работает стабильно.

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

В вашем случае тоже железо получается было, контроллер? Или софтовая бяка?

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

Решил покопаться дальше и обнаружил, что на таких же серверах G4, с таким же железом, на RAID-контроллере Smart Array 6i стоит более новая прошивка, а на двух глючных серверах: старая 2.34. Есть большое подозрение, что дело в этом. Обновил прошивку до последней версии 2.84(A), а заодно и остальные на G4. Теперь пока пару дней полет нормальный.

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