un carico elevato può causare l'arresto del server e l'errore "bloccato per più di 120 secondi"?

17

Attualmente in esecuzione alcuni server VM e "baremetal". Java è in esecuzione su alti - oltre il 400% + a volte. Casualmente il server si blocca con l'errore nella console "java - bloccato per più di 120 secondi" - kjournald, ecc.

Non riesco a ottenere un output di dmesg perché per qualche motivo questo errore scrive solo sulla console, a cui non ho accesso poiché è ospitato in remoto. quindi non riesco a copiare una traccia completa.

Ho cambiato l'ambiente in cui si trova, anche il server fisico e sta ancora accadendo.

Ho cambiato hung_task_timeout_secs a 0 in caso questo sia un falso positivo secondo http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html .

Inoltre, irqbalance non è installato, forse sarebbe d'aiuto?

questo è Ubuntu 10.04 a 64 bit - stesso problema con l'ultimo 2.6.38-15-server e 2.6.36.

cpu o problemi di memoria / nessuno scambio lasciato a causare questo problema?

ecco il messaggio della console:

[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

— Tee
fonte

15

Sì, potrebbe.

Ciò significa che è abbastanza esplicito: il kernel non è stato in grado di pianificare l'attività per 120 secondi. Ciò indica la fame di risorse, spesso attorno all'accesso al disco.

irqbalancepotrebbe aiutare, ma ciò non sembra ovvio. Puoi fornirci i dintorni di questo messaggio dmesg, in particolare la traccia dello stack che lo segue?

Inoltre, questo non è un falso positivo. Ciò non significa che l'attività sia sospesa per sempre e l'affermazione è perfettamente corretta. Ciò non significa che sia un problema per te e puoi decidere di ignorarlo se non noti alcun impatto dell'utente.

Ciò non può essere causato da:

un problema di CPU (o meglio, sarebbe un errore hardware follemente improbabile),
un problema di memoria (molto probabilmente un errore hardware, ma non si verificherebbe più volte; non una mancanza di RAM come sarebbe un processo oom-killed),
una mancanza di scambio (di oom-killernuovo).

In una certa misura, potresti essere in grado di incolpare questo per una mancanza di memoria, nel senso che privare il tuo sistema di memorizzazione dei dati nella cache causerà più I / O. Ma non è così semplice come "esaurire la memoria".

— Pierre Carrier
fonte

Non è stato registrato nulla su / var / log / dmesg, quindi ho appena incollato ciò che la console ha mostrato .. quando appare, il sistema è bloccato al 100%.

— Tee

Questo messaggio proviene dal kernel, apparirà dmesg(se è stato registrato abbastanza di recente) mentre questo comando stampa il buffer dell'anello di registrazione del kernel. Spero che anche il tuo syslogsetup lo acceda da qualche parte /var/log, ma non potrei sapere dove.

— Pierre Carrier,

Il messaggio NON verrà visualizzato in /var/log/dmesg, ma potrebbe essere visualizzato quando si esegue il dmesgcomando. Il file viene creato durante il processo di avvio e in genere acquisisce solo i messaggi del kernel all'avvio (che altrimenti finirebbero fuori dal buffer dell'anello del kernel. Si potrebbe anche installare / abilitare sysstate guardare l'utilizzo delle risorse come riportato qui. Sto sospettando il disco I / O / iowait, probabilmente correlato allo scambio (sysstat aiuterà a identificarlo).

— Dr. Edward Morbius,

@ Dr.EdwardMorbius Quindi, come possiamo risolvere questo problema? Sto riscontrando un grosso problema relativo a questo con il nostro server Zimbra che funzionava alla grande in un ambiente di produzione fino a poco tempo fa.

— Sbilenco il

@Lopsided: Scusate il ritardo, non sono qui spesso. In breve: dovrai profilare il tuo processo Java e scoprire perché è sospeso. La garbage collection è un'area in cui ho avuto problemi (e successi) nell'ottimizzazione. Cerca ergodymics JVM garbage collection e vedi oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Ho trovato che aumentare l'heap mi ha aiutato notevolmente.

— Dr. Edward Morbius,

6

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

Quindi eseguire il commit della modifica con:

sudo sysctl -p

risolto per me ....

— tacca
fonte

6

Dovresti spiegare cosa fanno ciascuna di queste impostazioni.

— Kasperd,

6

Questo risolto un problema simile che stavo riscontrando in un ambiente docker. Ho trovato una spiegazione qui: blackmoreops.com/2014/09/22/… . "Per impostazione predefinita, Linux utilizza fino al 40% della memoria disponibile per la memorizzazione nella cache del file system. Dopo che questo segno è stato raggiunto, il file system scarica tutti i dati in sospeso sul disco, facendo sì che tutti i seguenti IO diventino sincroni. un limite di tempo di 120 secondi per impostazione predefinita. Nel caso qui il sottosistema IO non è abbastanza veloce per scaricare i dati con ... "

— Peter M

2

Di recente ho riscontrato questo errore in uno dei nostri cluster di produzione:

11 nov 14:56:41 xxx kernel: INFO: task xfsalloc / 3: 2393 bloccato per più di 120 secondi.

11 nov 14:56:41 kernel Xxxx: non contaminato 2.6.32-504.8.1.el6.x86_64 # 1

11 nov 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" disabilita questo messaggio.

..

Su ulteriore verifica dei registri sar Trovato l'attesa IO è stata aumentata contemporaneamente.

E dopo aver verificato l'hardware (dischi fisici), sono stati rilevati errori medi e altri errori SCSI hanno registrato uno dei dischi fisici, che a sua volta stava bloccando gli IO, a causa della mancanza di risorse da allocare.

11/11/15 19:52:40: pRdm terminato 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Richiesta c1173100 Rispondi 60e06040 iocStatus 0048 riprovareC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11/11/15 19:52:40: DM_ProcessDevWaitQueue: Task mgmt in process devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: Task mgmt in process devId = x

Quindi questo era dovuto a un errore hardware, nel nostro cluster.

Quindi sarebbe bene, se potessi controllare il file core e anche se c'è l'utilità ipmi, controlla il comando sel elist ipmiutil / ipmitool per verificare il problema.

Saluti, VT

— Varun Thomas
fonte

0

Potresti andare all'interfaccia di monitoraggio del tuo provider cloud e verificare se non hai superato gli IOps massimi specificati per la tua memoria, questo spiegherebbe perché ci è voluto molto tempo per svuotare i dati della cache.
L'IOps massimo è disponibile nella pagina degli attributi di archiviazione.

— Emmanuel
fonte