Может ли высокая нагрузка вызвать зависание сервера и ошибка «заблокирована более чем на 120 секунд»?

17

В настоящее время работает несколько виртуальных машин и серверов «baremetal». 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-сервером и 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.

linux kernel

— тройник
источник

15

Да, это возможно.

Это означает, что ядро не может запланировать задачу на 120 секунд. Это указывает на нехватку ресурсов, часто из-за доступа к диску.

irqbalanceможет помочь, но это не кажется очевидным. Можете ли вы предоставить нам окружение этого сообщения dmesg, в частности трассировку стека, которая следует за ним?

Более того, это не ложный позитив. Это не говорит о том, что задача повешена навсегда , и утверждение совершенно правильно. Это не значит, что это проблема для вас, и вы можете проигнорировать ее, если не заметите влияния на пользователя.

Это не может быть вызвано:

проблема с процессором (или, скорее, это было бы невероятно аппаратной ошибкой),
проблема с памятью (очень маловероятно, что произошел сбой аппаратного обеспечения, но это не произойдет многократно; не как бы нехватка оперативной памяти, как процесс oom-killed)
отсутствие свопа ( oom-killerопять же).

В некоторой степени вы можете обвинить это в недостатке памяти в том смысле, что лишение вашей системы кэширования данных в ОЗУ приведет к увеличению количества операций ввода-вывода. Но это не так просто, как «не хватает памяти».

— Пьер Кэрриер
источник

В / var / log / dmesg ничего не записывается, поэтому я просто вставил то, что показала Консоль ... когда это кажется, система зависла на 100%.

— Ти

Это сообщение исходит от ядра, оно появится dmesg(если оно было зарегистрировано достаточно недавно), так как эта команда печатает буферный журнал ядра. Надеюсь, ваши syslogнастройки также будут где-то регистрироваться /var/log, но я не мог знать где.

— Пьер Кэрриер

Сообщение НЕ появится /var/log/dmesg, но может появиться при запуске dmesgкоманды. Файл создается во время процесса загрузки и, как правило, захватывает только сообщения ядра во время загрузки (которые в противном случае могли бы в конечном итоге прокрутиться из кольцевого буфера ядра. Вы также можете установить / включить sysstatи посмотреть использование ресурсов, как сообщалось там. Я подозреваю диск I / O / iowait, вероятно, связанный с обменом (sysstat поможет определить это)

— доктор Эдвард Морбиус

@ Dr.EdwardMorbius Итак, как нам это исправить? У меня возникла серьезная проблема, связанная с этим, с нашим сервером Zimbra, который до недавнего времени прекрасно работал в производственной среде.

— однобоко

@Lopsided: извините за задержку, я здесь не часто. Вкратце: вам придется профилировать свой процесс Java и выяснить, почему он зависает. Сборка мусора - одна из областей, в которой у меня были проблемы (и успехи) в настройке. Посмотрите эргодичность сборки мусора в JVM и посмотрите oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Я обнаружил, что увеличение кучи помогло заметно.

— Доктор Эдвард Морбиус

6

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

Затем внесите изменения с помощью:

sudo sysctl -p

решил это для меня ....

— Ник
источник

6

Вы должны объяснить , что каждый эти параметры делают.

— kasperd

6

Это устранило аналогичную проблему, с которой я столкнулся в среде докеров. Я нашел объяснение здесь: blackmoreops.com/2014/09/22/… . «По умолчанию Linux использует до 40% доступной памяти для кэширования файловой системы. После достижения этой отметки файловая система сбрасывает все ожидающие данные на диск, в результате чего все последующие операции ввода-вывода становятся синхронными. Для сброса этих данных на диск это ограничение по времени составляет 120 секунд по умолчанию. В данном случае подсистема ввода-вывода недостаточно быстрая, чтобы сбрасывать данные в процессе ... "

— Питер М.

2

Недавно я прошел через эту ошибку в одном из наших производственных кластеров:

11 ноября 14:56:41 xxx ядро: ИНФОРМАЦИЯ: задача 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: задание mgmt в процессе devId = x 11.11.15 19:52:40: DM_ProcessDevWaitQueue: задание mgmt в процессе devId = x

Так что это произошло из-за аппаратной ошибки в нашем кластере.

Так что было бы хорошо, если бы вы могли проверить файл ядра, а также, если есть утилита ipmi, проверьте команду ipmiutil / ipmitool sel elist, чтобы проверить проблему.

С уважением, VT

— Варун Томас
источник

0

Вы можете перейти к интерфейсу мониторинга вашего облачного провайдера и проверить, не превышали ли вы максимальные значения операций ввода-вывода, указанные для вашего хранилища, что объясняет, почему для очистки данных кэша потребовалось много времени.
Максимальное количество операций ввода-вывода доступно на странице атрибутов хранилища.

— Эммануэль
источник