Bonjour à tous,

Vous l'aurez sans doute constaté, mais Lexpage est devenu particulièrement instable ces derniers jours, et surtout ces dernières heures, au poins de crasher complètement dans la soirée du 28 et dans la nuit du 28 au 29. Ces instabilités se traduisent par des latences élevées qui, en général, provoquent soit un "site introuvable", soit une erreur interne au site.

Je n'ai pas encore trouvé la cause de ces soucis : il semblait à priori que ça soit lié à la base de données et à la librairie utilisée pour s'y connecter, mais il semble maintenant que le problème soit plus "profond" que ça, puisqu'en monitorant les services, je me suis rendu compte que c'était l'ensemble du système qui freezait régulièrement, et que les problèmes cités ci-dessus ne sont que les symptômes de ces freezes.

Un petit tour du coté des logs kernels confirme cela :

[49519.868188] BUG: soft lockup - CPU#0 stuck for 27s! [postmaster:11523]
[49737.603071] BUG: soft lockup - CPU#0 stuck for 26s! [gunicorn:11548]
[52959.928909] BUG: soft lockup - CPU#0 stuck for 22s! [python:12107]
[53577.894825] BUG: soft lockup - CPU#0 stuck for 28s! [chronyd:500]
[54238.620660] BUG: soft lockup - CPU#0 stuck for 22s! [gunicorn:12372]
[54847.058982] BUG: soft lockup - CPU#0 stuck for 28s! [gunicorn:12507]
[56439.191993] BUG: soft lockup - CPU#0 stuck for 21s! [postmaster:13298]
[56627.181319] BUG: soft lockup - CPU#0 stuck for 28s! [cat:13507]
[58801.218862] BUG: soft lockup - CPU#0 stuck for 27s! [gunicorn:14025]
[59917.072027] BUG: soft lockup - CPU#0 stuck for 23s! [nginx:10188]
[61566.624361] BUG: soft lockup - CPU#0 stuck for 29s! [gunicorn:14548]
[63742.932341] BUG: soft lockup - CPU#0 stuck for 29s! [python:14815]

Y a une trace d'exécution qui suit chaque message, ainsi que les infos sur les modules chargés dans le noyau et utilisé à ce moment. Le hic, c'est que je ne sais pas du tout comment débogguer ça...

En attendant, j'ai contacté OVH pour signaler le problème, vu que ça se produit également quand l'ensemble des processus sont au repos (ce qui signifie que le "blocage" a lieu depuis une activité extérieure, sans doute les "autres clients" VPS).

Un de mes vps rencontre également le soucis depuis cette nuit, alors qu'il n'est pas sur un des hosts où ovh signale un problème. Les erreurs que j'avais dans le dmesg concernaient toutes des allocations mémoires qui n'aboutissaient pas, alors que j'étais largement dans mon quota avec une conso d'environ 600M/2G. Couper des containers et libérer 200M de ram n'a pas résolu le soucis, les erreurs continuaient de s'empiler. Entre ça et tes soucis de cpu stuck je soupçonne un overcommit bien trop bourrin qui se retourne contre ovh.

J'ai rebooté mon vps pour la forme et il a mis du temps avant de revenir. J'aurais dû mieux noter sur quel host il était car je pense qu'ils ont dû me le migrer sur un autre à cette occasion, en dehors de ce reboot long je n'ai plus aucun soucis depuis une heure alors que mon dmesg se faisait vraiment spammer de messages.

Cela me rassure que tu aies rencontré des soucis également, je me sens moins seul

J'ai déjà rebooté le VPS hier, mais je vais le refaire d'ici quelques minutes, "au cas où". En attendant, je ne vois pas trop comment faire pour relancer Lexpage automatiquement quand un des workers plantent à la relance. Mon systemd n'est pas prévu pour ça (il n'en est même pas au courant, c'est gunicorn qui gère ça, et je ne suis pas sûr que ça soit "sain" de forcer la relance automatique, au cas où une vraie erreur grave se produit). Du coup, j'ai installé un client SSH sur mon téléphone, pour relancer le site même quand je ne suis pas à la maison

Voilà. J'ai l'impression que je suis passé de "Strasbourg" (SGB1) à "Gravelines" (GRA1) pour l'instance du VPS. J'aurai du vérifier avant (surtout que tu en as parlé dans ton mail ).