INFO: task <task:ID> blocked for more than 120 seconds

слишком большая нагрузка на IO-подсистему, смотри iostat и зарезай число http-соединений

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

Да и сейчас, когда начал разворачивать сервак, на нем никого кроме меня не было.

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

как минимум пять активных процессов апача и два процесса mc я не придумал, а увидел на скриншоте

скорее всего постепенно дохнет какой-то хард — пока еще ухитряется читать, но не с первого раза, поэтому дико медленно; смотри SMART всех дисков

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

А, все, опции указал, щас погляжу.

Сваппинг.

У меня все так и было, только на рейзере.

leg0las

А ФС какая? ext4 ?

Я просто выполнил полную проверку by fsck и вроде как прошло.

хардварный сказевый рейд

если с нуля, то может и рейд глючит
смотри iostat в момент тормозов; если редко, то пиши в файл: iostat -txm 10, потом найдешь скачок IO-нагрузки и узнаешь на какой раздел

сваппинг

как вариант, тоже увидишь

Была xfs вроде. Сейчас ext4 везде.

Посмотрел смартом

smartctl -a -d cciss,X /dev/cciss/c0d0

ошибок 0, хотя инфа немного по разному отображается. Накатали старые винты кстати 56,5к часов.

хардварный сказевый рейд

а конфигурацию сразу слабо было написать?

если с нуля, то может и рейд глючит

Теперь бы поймать, заразу

смотри iostat в момент тормозов

В том то и проблема, если глючит - обязательно (обычно так) ночью, да и виснет так, что залогинится нельзя, только REISUB, хотя между tty-ями бегает.

а конфигурацию сразу слабо было написать?

Я как бы конкретную модель сервака привел

А так:

# lspci | grep -i raid
04:03.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01)
06:01.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01)

Я как бы конкретную модель сервака привел

пля, RAID какой номер? сколько дисков, как построены?

виснет так, что залогинится нельзя

запусти в фоне процесс записи статистики и оставь на ночь; когда зависнет, после перезагрузки найдешь файл и посмотришь; лучше писать на независимый диск, например флешку воткни и на нее пиши

Был 1, (два винта), после докидывания еще двух сделал 10.

Винты (все 4):

Vendor:               COMPAQ  
Product:              BD14687B52      
Revision:             HPB{4|5}
User Capacity:        146 815 737 856 bytes [146 GB]
Logical block size:   512 bytes
...
Device type:          disk
Transport protocol:   Parallel SCSI (SPI-4)
Local Time is:        Mon Jan 13 16:53:33 2014 EET
Device supports SMART and is Enabled
Temperature Warning Enabled

Сваппинг.

ну и

$ free

1GB на сервере?
no way

запусти вот так в фоне и оставь на ночь:

# while true; do iostat -txm; top -bcn1; sleep 10; done &> /.../somefile.log &

no way

На больше денег не дают:-(

Ок, запущу на ночь. Щас решил прогнать так:

dd if=/dev/zero of=/var/image.tmp bs=1K count=104857600

Прогнал винты на наличие бэдов - найдено 0.

Печалька. Кстати, после запуска скрипта с логгированием сервак как назло отпахал безотказно.

да и виснет так, что залогинится нельзя, только REISUB, хотя между tty-ями бегает

было такое
через полчаса ожил
LA было около 200
поэтому и не логинился
имхо

Сабжевое сообщение возникает когда процесс слишком долго находится в D-состоянии (TASK_UNINTERRUPTIBLE). Это специальное хитрое состояние, обозначающее примерно следующее: «Мы вошли в область ядра, которую по-идее должны мгновенно проскочить, но если там чего-то застрянет, то оно застрянет там навсегда, а нам слишком влом трахаться с прерыванием».

Можно сделать так что ядро по этому поводу будет паниковать.

По идее, это — баг. Во всяких NFS и SMB — не баг, таймаут TCP 300 секунд.

Еще, такая штука возможна из-за неправильного использования сокетов.

Что за процесс-то?

Прогнал винты на наличие бэдов - найдено 0.

fsck что ли? дык это зря! если ошибка физическая, но пока не фатальная (т.е. в конце концов успешно читает данные, просто тратит много попыток) и не постоянная, то на уровне файловой системы ты ее не увидишь — надо смотреть SMART

Печалька. Кстати, после запуска скрипта с логгированием сервак как назло отпахал безотказно.

так часто бывает :)
оставь на подольше

если mc, который просто запущен, и не взаимодействует с пользователем (ночью), т.е. ничего делать не должен, ушел в анинтерраптбл_слип, то скорее всего кончилась память -> ядро стало вытеснять все подряд в swap -> он тоже заполнился под завязку -> все встало колом, т.к. OOM-killer тоже не может прибить жрущий память процесс, ведь он в статусе TASK_UNINTERRUPTIBLE.

iostat, как я и говорил, покажет все это, надо только дождаться нового случая; а еще полезно было бы top или ps сохранять периодически, чтобы потом узнать, какой именно процесс сожрал память

системные логи, полагаю (хотя теперь засомневался), уже были обследованы на предмет подозрительных сообщений в районе «незадолго до зависона»?

Такое бывает при сваппинге и oom чаще всего, инфа 100%.

Не fsck конечно, регенераторм вроде. Сотрудник прогонял свой битый винт им, я его заюзал.

Решил отрубить старые винты и написал тест на баше - dd urandom, нагрузка на ОЗУ (через tmpfs), на винт и i/o - /dev/zero. С логгированием, посмотрим, что выйдет.

системные логи, полагаю (хотя теперь засомневался), уже были обследованы

естественно, и не один раз. оно тупо отваливается без каких-либо варнингов/ошибок, вообще без никаких сообщений. В dmesg кстати тоже ошибок нет, при поврежденном рейде оно вроде туда пишет.

Откуда взяться сваппингу на свежеустановленной системе?