une charge élevée peut-elle provoquer un blocage du serveur et une erreur «bloquée pendant plus de 120 secondes»?

17

Exécute actuellement quelques machines virtuelles et serveurs «baremetal». Java fonctionne à un niveau élevé - plus de 400% + parfois. Au hasard, le serveur se bloque avec l'erreur dans la console "java - bloqué pendant plus de 120 secondes" - kjournald, etc.

Je ne peux pas obtenir une sortie dmesg car pour une raison quelconque, cette erreur écrit uniquement sur la console, à laquelle je n'ai pas accès car elle est hébergée à distance. par conséquent, je ne peux pas copier une trace complète.

J'ai changé l'environnement sur lequel il se trouve - même le serveur physique et cela continue.

J'ai changé hung_task_timeout_secs à 0, car il s'agit d'un faux positif selon http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html .

De plus, irqbalance n'est pas installé, peut-être que cela aiderait?

il s'agit d'Ubuntu 10.04 64bit - même problème avec les derniers serveurs 2.6.38-15 et 2.6.36.

des problèmes de processeur ou de mémoire / aucun échange ne peuvent-ils provoquer ce problème?

voici le message de la 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
source

15

Oui, c'est possible.

Ce que cela signifie est assez explicite: le noyau n'a pas pu planifier la tâche pendant 120 secondes. Cela indique un manque de ressources, souvent autour de l'accès au disque.

irqbalancepourrait aider, mais cela ne semble pas évident. Pouvez-vous nous fournir l'environnement de ce message dmesg, en particulier la trace de pile qui le suit?

De plus, ce n'est pas un faux positif. Cela ne signifie pas que la tâche est suspendue pour toujours , et la déclaration est parfaitement correcte. Cela ne signifie pas que c'est un problème pour vous, et vous pouvez décider de l'ignorer si vous ne remarquez aucun impact sur l'utilisateur.

Cela ne peut pas être causé par:

un problème de CPU (ou plutôt, ce serait une panne matérielle incroyablement improbable),
un problème de mémoire (très probablement une défaillance matérielle, mais ne se produirait pas plusieurs fois; pas un manque de RAM comme un processus oom-killed),
un manque de swap ( oom-killerencore).

Dans une large mesure, vous pourriez être en mesure de blâmer cela sur un manque de mémoire dans le sens où priver votre système de mise en cache des données dans la RAM entraînera plus d'E / S. Mais ce n'est pas aussi simple que «manquer de mémoire».

— Pierre Carrier
source

Il n'y a rien en cours d'enregistrement dans / var / log / dmesg donc j'ai juste collé ce que la console a montré .. quand cela apparaît, le système est bloqué à 100%.

— Tee

Ce message provient du noyau, il apparaîtra dans dmesg(s'il a été enregistré assez récemment) car cette commande imprime le tampon d'anneau de journalisation du noyau. J'espère que votre syslogconfiguration le connectera également quelque part /var/log, mais je ne savais pas où.

— Pierre Carrier

Le message n'apparaîtra pas dans /var/log/dmesg, mais peut apparaître lorsque vous exécutez la dmesgcommande. Le fichier est créé pendant le processus de démarrage et ne capture généralement que les messages du noyau au démarrage (qui autrement finiraient par défiler hors du tampon d'anneau du noyau. Vous pouvez également installer / activer sysstatet regarder l'utilisation des ressources comme indiqué ici. Je soupçonne que le disque I / O / iowait, probablement liés à l'échange (sysstat aidera à identifier cela).

— Dr. Edward Morbius

@ Dr.EdwardMorbius Alors, comment pouvons-nous résoudre ce problème? J'ai un problème majeur lié à cela avec notre serveur Zimbra qui fonctionnait très bien dans un environnement de production jusqu'à récemment.

— Lopsided

@Lopsided: Désolé pour le retard, je ne suis pas souvent là. En bref: vous devrez profiler votre processus Java et découvrir pourquoi il se bloque. La récupération de place est un domaine dans lequel j'ai eu des problèmes (et des succès) dans le réglage. Recherchez l'ergodymique de la récupération de place JVM et consultez oracle.com/technetwork/java/javase/gc-tuning-6-140523.html .

— Dr.Edward Morbius

6

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

Validez ensuite le changement avec:

sudo sysctl -p

résolu pour moi ....

— pseudo
source

6

Vous devez expliquer ce que font chacun de ces paramètres.

— kasperd

6

Cela a résolu un problème similaire que j'avais dans un environnement de docker. J'ai trouvé une explication ici: blackmoreops.com/2014/09/22/… . "Par défaut, Linux utilise jusqu'à 40% de la mémoire disponible pour la mise en cache du système de fichiers. Une fois cette marque atteinte, le système de fichiers vide toutes les données en attente sur le disque, ce qui entraîne la synchronisation de toutes les E / S suivantes. Pour purger ces données sur le disque, il existe une limite de temps de 120 secondes par défaut. Dans le cas ici, le sous-système d'E / S n'est pas assez rapide pour vider les données au fil du temps ... "

— Peter M

2

J'ai récemment rencontré cette erreur dans l'un de nos clusters de production:

11 novembre 14:56:41 noyau xxx: INFO: tâche xfsalloc / 3: 2393 bloquée pendant plus de 120 secondes.

11 novembre 14:56:41 Noyau Xxxx: non contaminé 2.6.32-504.8.1.el6.x86_64 # 1

11 novembre 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" désactive ce message.

..

Après vérification supplémentaire des journaux sar Trouvé, l'attente d'E / S a été augmentée pendant la même période.

Et lors de la vérification du matériel (disques physiques), des erreurs moyennes et d'autres erreurs SCSI se sont connectées à l'un des disques physiques, ce qui bloquait les E / S, en raison du manque de ressources à allouer.

11/11/15 19:52:40: drapeaux pRdm 607b8000 terminés = 0 TimeOutC = 0 RetryC = 0 Request c1173100 Répondre 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11/11/15 19:52:40: DM_ProcessDevWaitQueue: Tâche mgmt dans le processus devId = x 11/11/15 11:52:40: DM_ProcessDevWaitQueue: Tâche mgmt dans le processus devId = x

Cela était donc dû à une erreur matérielle, dans notre cluster.

Donc, ce serait bien, si vous pouviez vérifier le fichier principal et aussi si l'utilitaire ipmi est là, vérifiez la commande selmiist ipmiutil / ipmitool pour vérifier le problème.

Cordialement, VT

— Varun Thomas
source

0

Vous pouvez accéder à l'interface de surveillance de votre fournisseur de cloud et vérifier si vous n'avez pas dépassé le nombre maximal d'E / S spécifié pour votre stockage, ce qui expliquerait pourquoi il a fallu beaucoup de temps pour vider les données du cache.
Le nombre maximal d'E / S est disponible sur votre page d'attributs de stockage.

— Emmanuel
source