BUG: soft lockup - CPU#1

Tags: #<Tag:0x00007f63f3f09688> #<Tag:0x00007f63f3f093e0>

Bonjour à tous,
J’ai un serveur ESX 6.7 et une baie de disques pour le stockage des vms. La quasi totalité de mes vms sont sous debian 8.

Les vms les plus sollicitées (en restant loin des perfs max) m’affichent ça diectement dans mon shell :
Message from syslogd@erp at Nov 21 10:03:43 …
kernel:[776643.847901] BUG: soft lockup - CPU#1 stuck for 22s! [Threadpool work:19127]

J’arrive difficilement à me connecter en SSH mais tous les autres services sont down.

Avez vous déjà rencontré ce problème? J’ai beau fouiller, je ne trouve pas de solution.

Je vous remercie d’avance.

Bonne journée à vous,

Il semble que ça corresponde à un plafond de ressources atteint (genre nombre de threads, si j’en crois la mention “threadpool”).
Il faudrait ajuster kernel.watchdog_thresh avec sysctl pour doubler sa valeur, si j’en crois cet article suse assez explicatif, déjà ça diminuera le nombre de messages.
Aprés, il faudrait rentrer dans le détail des messages d’erreurs de pile qui viennent aprés celui que tu as indiqué, et/ou “dumper le noyau” au moment du lock pour analyser.

https://www.suse.com/support/kb/doc/?id=7017652
Traduction auto:

La situation
Dans le journal système (/var/log/messages ou journalctl) un grand nombre des messages suivants est imprimé.
25 mai 07:23:23:59 XXXXXXXXX kernel : 13445315.881356] BUG : soft lockup - CPU#16 coincé depuis 23s ! [yyyyyyyyyyyy:81602]

suivi de diverses traces de pile. Ce document tente d’expliquer ce que signifient les messages de blocage logiciel.

Résolution
Dans des circonstances normales, ces messages peuvent disparaître si la charge diminue.
Ce’blocage progressif’ peut se produire si le noyau est occupé, travaillant sur un grand nombre d’objets qui doivent être scannés, libérés ou alloués respectivement.
Les traces de la pile de ces tâches peuvent donner une première idée de ce que les tâches faisaient. Cependant, pour pouvoir examiner la cause derrière les messages, un dump du noyau serait nécessaire.

Vous ne pouvez pas désactiver ces messages, cependant, dans certaines situations, vous pouvez augmenter l’heure à laquelle ces messages sont envoyés.
des fermetures douces seront déclenchées peuvent détendre la situation.
Pour ce faire, il suffit d’augmenter le paramètre sysctl suivant : kernel.watchdog_thresh
La valeur par défaut de ce paramètre est 10 et doubler la valeur pourrait être un bon début.

Un TID expliquant comment configurer et capturer le dump du noyau est disponible sur le site Web d’assistance SUSE.
Cause
Un’blocage logiciel’ est défini comme un bogue qui fait que le noyau tourne en boucle en mode noyau pendant plus de 20 secondes, sans donner aux autres tâches une chance de s’exécuter.
Le démon Watchdog enverra une interruption non masquable (NMI) à tous les CPU du système qui imprimeront à leur tour les traces de la pile de leurs tâches en cours.

Et sinon, sysctl m’indique un seul paramètre noyau parlant de threads:
kernel.threads-max = 513056 (chez moi)
Peut être en augmentant ?

Mattotop, merci pour ta réponse et désolé pour le retard de la mienne… J’ai chercher par rapport aux infos que tu m’as donné.
J’ai une machine qui n’a jamais planté avec le kernel en 4.9.0-6 et celles qui plantes en 3.16.0-4.
La différence de version est due au client de mon logiciel de PRA. Je dois trouver le moyen de repasser sur le bon kernel sans pour autant planter le logiciel et surtout sans casser la prod.
Merci beaucoup pour ton aide.
Je te tiens au courant.