web-dev-qa-db-fra.com

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

Exécute actuellement quelques machines virtuelles et serveurs "baremetal". Java fonctionne en haut - plus de 400% + parfois. Aléatoire, le serveur se bloque avec l'erreur dans la console "Java - bloqué pendant plus de 120 secondes" - kjournald, etc.

Je ne peux pas obtenir de 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.
linuxkernel
17
Tee

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.

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

De plus, c'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 car un processus serait oom-killed),
  • un manque de swap (oom-killer encore).

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 RAM entraînera plus d'E/S. Mais ce n'est pas aussi simple que " manque de mémoire ".

15
Pierre Carrier
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 ....

6
Nick

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.

..

Lors d'une vérification supplémentaire des journaux sar Trouvé, l'attente IO a été augmentée pendant le même temps.

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 de base et aussi si l'utilitaire ipmi est là, recherchez la commande ipmiutil/ipmitool sel elist pour vérifier le problème.

Cordialement, VT

2
Varun Thomas

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.

0
Emmanuel