В настоящее время запущено несколько виртуальных машин и серверов без операционной системы. Java работает на высоком уровне - временами более 400% +. Случайно зависает сервер с ошибкой в консоли «java - заблокирован более 120 секунд» - kjournald и т. Д.
Я не могу получить вывод dmesg, потому что по какой-то причине эта ошибка записывается только в консоль, к которой у меня нет доступа, поскольку она размещена удаленно. поэтому не могу скопировать полный след.
Я изменил среду, в которой это находится - даже физический сервер, и это все еще происходит.
Я изменил hung_task_timeout_secs на 0, если это ложное срабатывание согласно http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html .
Также не устанавливается irqbalance, может, поможет?
это Ubuntu 10.04 64bit - такая же проблема с последними версиями 2.6.38-15-server и 2.6.36.
Могут ли проблемы с процессором или памятью / отсутствие подкачки вызвать эту проблему?
вот сообщение консоли:
[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
Да, может.
Это означает довольно ясно: ядро не могло запланировать задачу на 120 секунд. Это указывает на нехватку ресурсов, часто из-за доступа к диску.
irqbalance может помочь, но это не кажется очевидным. Можете ли вы предоставить нам окружение этого сообщения в dmesg, в частности, трассировку стека, которая следует за ним?
Более того, это не ложное срабатывание. Это не говорит о том, что задача зависла навсегда, и утверждение совершенно правильно. Это не значит, что это проблема для вас, и вы можете проигнорировать ее, если не заметите никакого воздействия на пользователя.
Это не может быть вызвано:
oom-killed),oom-killer очередной раз).В некоторой степени вы могли бы винить это в нехватке памяти в том смысле, что лишение вашей системы кэширования данных в ОЗУ приведет к увеличению количества операций ввода-вывода. Но это не так просто, как «нехватка памяти».
sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5
Затем зафиксируйте изменение с помощью:
sudo sysctl -p
решил это для меня ....
Недавно я столкнулся с этой ошибкой в одном из наших производственных кластеров:
11 ноября, 14:56:41 xxx kernel: INFO: задача xfsalloc / 3: 2393 заблокирована более 120 секунд.
11 ноября, 14:56:41 Ядро Xxxx: не испорчено 2.6.32-504.8.1.el6.x86_64 # 1
11 ноября, 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" отключает это сообщение.
..
При дальнейшей проверке найденных журналов sar время ожидания ввода-вывода было увеличено в то же время.
И после проверки оборудования (физических дисков) обнаружил, что ошибки среды и другие ошибки SCSI были зарегистрированы на одном физическом диске, который, в свою очередь, блокировал операции ввода-вывода из-за нехватки ресурсов для распределения.
11/11/15 19:52:40: завершено pRdm 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Запрос c1173100 Ответ 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000
11/11/15 19:52:40: DM_ProcessDevWaitQueue: управление задачей в процессе devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: управление задачей в процессе devId = x
Значит, это произошло из-за аппаратной ошибки в нашем кластере.
Так что было бы хорошо, если бы вы могли проверить наличие основного файла, а также наличие утилиты ipmi, проверьте команду ipmiutil / ipmitool sel elist, чтобы проверить наличие проблемы.
С уважением, VT
Вы можете перейти к интерфейсу мониторинга вашего облачного провайдера и проверить, не превысили ли вы максимальное количество операций ввода-вывода, указанное для вашего хранилища, что объяснило бы, почему на очистку данных кеша ушло много времени.
Максимальное количество операций ввода-вывода доступно на странице атрибутов хранилища.