czy wysokie obciążenie może spowodować zawieszenie się serwera i błąd „zablokowany na ponad 120 sekund”?

17

Obecnie działa kilka maszyn wirtualnych i serwerów „baremetal”. Java działa na wysokim poziomie - czasami ponad 400% +. Losowo serwer zawiesza się z błędem w konsoli „java - zablokowany na ponad 120 sekund” - kjournald itp.

Nie mogę uzyskać wyjścia dmesg, ponieważ z jakiegoś powodu ten błąd zapisuje tylko konsolę, do której nie mam dostępu, ponieważ jest on zdalnie hostowany. dlatego nie mogę skopiować pełnego śladu.

Zmieniłem środowisko, w którym jest włączony - nawet fizyczny serwer i nadal tak się dzieje.

Zmieniłem hung_task_timeout_secs na 0, ponieważ jest to fałszywy alarm zgodny z http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html .

Ponadto, nierównowaga nie jest zainstalowana, może to pomoże?

jest to Ubuntu 10.04 64bit - ten sam problem z najnowszymi serwerami 2.6.38-15 i 2.6.36.

czy problemy z procesorem lub pamięcią / brak zamiany nie może spowodować tego problemu?

oto komunikat konsoli:

[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

— Trójnik
źródło

15

Tak, może.

Oznacza to, że jest to dość wyraźne: jądro nie mogło zaplanować zadania na 120 sekund. Wskazuje to na głód zasobów, często w pobliżu dostępu do dysku.

irqbalancemoże pomóc, ale to nie wydaje się oczywiste. Czy możesz podać nam otoczenie tej wiadomości dmesg, w szczególności ślad stosu, który następuje po niej?

Co więcej, nie jest to fałszywy pozytyw. Nie oznacza to, że zadanie zostało zawieszone na zawsze , a stwierdzenie jest całkowicie poprawne. To nie znaczy, że jest to dla ciebie problem i możesz zdecydować się go zignorować, jeśli nie zauważysz żadnego wpływu użytkownika.

Nie może to być spowodowane:

problem z procesorem (a raczej byłby to niesamowicie nieprawdopodobna awaria sprzętu),
problem z pamięcią (bardzo nieprawdopodobna awaria sprzętu, ale nie zdarzyła się wiele razy; nie brak pamięci RAM jako procesu oom-killed),
brak zamiany ( oom-killerponownie).

Do pewnego stopnia możesz być winny temu brak pamięci w tym sensie, że pozbawienie systemu buforowania danych w pamięci RAM spowoduje więcej operacji we / wy. Ale to nie jest tak proste, jak „brak pamięci”.

— Pierre Carrier
źródło

Nic nie jest rejestrowane w / var / log / dmesg, więc właśnie wkleiłem to, co pokazała konsola .. kiedy to się pojawi, system jest w 100% zawieszony.

— Tee

Ten komunikat pochodzi z jądra, pojawi się w dmesg(jeśli był zalogowany wystarczająco wcześnie), ponieważ to polecenie wypisuje bufor pierścieniowy rejestrowania jądra. Mam nadzieję, że twoja syslogkonfiguracja również gdzieś się zaloguje /var/log, ale nie wiedziałem gdzie.

— Pierre Carrier

Komunikat NIE pojawi się /var/log/dmesg, ale może pojawić się po uruchomieniu dmesgpolecenia. Plik jest tworzony podczas procesu uruchamiania i generalnie przechwytuje tylko komunikaty jądra w czasie rozruchu (które w przeciwnym razie ostatecznie przewiną się z bufora pierścienia jądra. Możesz także zainstalować / włączyć sysstati spojrzeć na wykorzystanie zasobów, jak tam zgłoszono. I / O / iowait, prawdopodobnie związane z zamianą (sysstat pomoże to zidentyfikować)

— Dr Edward Morbius

@ Dr.EdwardMorbius Więc jak to naprawić? Mam poważny problem z tym związany z naszym serwerem Zimbra, który do niedawna działał świetnie w środowisku produkcyjnym.

— Lopsided

@Lopsided: Przepraszam za opóźnienie, nie jestem tu często. W skrócie: musisz profilować proces Java i dowiedzieć się, dlaczego się on zawiesił. Śmieci to jeden z obszarów, w którym miałem problemy (i sukcesy) w tuningu. Poszukaj ergodymiki zbierania śmieci JVM i zobacz oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Znalazłem, że zwiększenie sterty znacznie pomogło.

— Dr Edward Morbius

6

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

Następnie zatwierdź zmianę za pomocą:

sudo sysctl -p

rozwiązał to dla mnie ....

— Nacięcie
źródło

6

Powinieneś wyjaśnić, co robią te ustawienia.

— kasperd

6

To naprawiło podobny problem, który miałem w środowisku dokera. Znalazłem wyjaśnienie tutaj: blackmoreops.com/2014/09/22/… . „Domyślnie Linux zużywa do 40% dostępnej pamięci do buforowania systemu plików. Po osiągnięciu tego znaku system plików opróżnia wszystkie zaległe dane na dysk, powodując synchronizację wszystkich następnych operacji we / wy. domyślnie limit czasu wynosi 120 sekund. W tym przypadku podsystem IO nie jest wystarczająco szybki, aby opróżnić dane za pomocą ... ”

— Peter M

2

Niedawno przeszedłem przez ten błąd w jednym z naszych klastrów produkcyjnych:

11 listopada 14:56:41 xxx jądro: INFO: zadanie xfsalloc / 3: 2393 zablokowane na ponad 120 sekund.

11 listopada 14:56:41 Jądro Xxxx: nie skażone 2.6.32-504.8.1.el6.x86_64 # 1

11 listopada 14:56:41 xxx: „echo 0> / proc / sys / kernel / hung_task_timeout_secs” wyłącza tę wiadomość.

..

Po dalszej weryfikacji dzienników sar stwierdzono, że czas oczekiwania IO został zwiększony w tym samym czasie.

A po sprawdzeniu Sprzętu (Dysków Fizycznych) zobaczyłem średnie błędy i inne Błędy SCSI zalogowały się na jednym Dysku Fizycznym, który z kolei blokował IO z powodu braku zasobów do przydzielenia.

11/11/15 19:52:40: zakończony pRdm 607b8000 flagi = 0 TimeOutC = 0 Ponów próbę = 0 Poproś c1173100 Odpowiedz 60e06040 iocStatus 0048 spróbuj ponownie 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11/11/15 19:52:40: DM_ProcessDevWaitQueue: Zadanie mgmt w procesie devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: Zadanie mgmt w procesie devId = x

Było to spowodowane błędem sprzętowym w naszym klastrze.

Byłoby dobrze, gdybyś mógł sprawdzić plik podstawowy, a także jeśli narzędzie ipmi jest dostępne, sprawdź polecenie ipmiutil / ipmitool sel elist, aby sprawdzić problem.

Pozdrawiam, VT

— Varun Thomas
źródło

0

Możesz przejść do interfejsu monitorowania dostawcy usług w chmurze i sprawdzić, czy nie przekroczono maksymalnych IOps określonych dla magazynu, co wyjaśniałoby, dlaczego opróżnianie pamięci podręcznej zajęło dużo czasu.
Maksymalna liczba operacji wejścia / wyjścia jest dostępna na stronie atrybutów magazynu.

— Emmanuel
źródło