може велике навантаження спричинити зависання сервера та помилку "заблоковану більше 120 секунд"?

17

В даний час працює декілька серверів VM і 'бареметал'. 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 ядро: 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 Виявлено, що час очікування IO був збільшений.

А після перевірки Апаратних засобів (фізичних дисків) побачили середні помилки, а інші помилки SCSI зареєструвались на одному Фізичні диски, що, в свою чергу, блокувало IO, через відсутність виділених ресурсів.

11.11.15 19:52:40: терміновані прапорці pRdm 607b8000 = 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 для перевірки проблеми.

З повагою, В.Т.

— Варун Томас
джерело

0

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

— Еммануїл
джерело