Depuis que j’ai migré mon grand forum vers Discourse cette année, j’ai constaté des plantages peu fréquents où la VM cloud devenait inaccessible via SSH et présentait une trace d’appel sur la console virtuelle. Les plantages se produisent environ toutes les 3 à 6 semaines sans schéma spécifique. J’utilisais initialement Discourse sur Clear Linux car c’est ce que j’utilisais pour obtenir un peu plus de performance du système pendant la longue et intensive migration de l’ancien forum vers Discourse. Mais j’ai commencé à suspecter que Clear Linux était peut-être moins stable en raison de toutes ses optimisations de performance obscures, j’ai donc migré mon Discourse vers Debian 12 Bookworm au moment de sa sortie, il y a environ 6 semaines.
Malheureusement, aujourd’hui, le système Debian a eu son premier plantage. Voici la séquence des événements :
kernel: Voluntary context switch within RCU read-side critical section!
kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
journalctl montre la dernière entrée de journal à 06:40:50. Mais le système d’exploitation et Discourse fonctionnaient toujours. La dernière entrée était juste un bavardage standard de l’agent de messagerie dockerisé que j’exécute sur la même VM.
Vers 08:30, j’ai vérifié que Discourse était opérationnel et fonctionnait normalement.
08:46 dans le journal d’erreurs de Discourse : Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
08:53 dans le journal d’erreurs de Discourse : Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
09:01 dans le journal d’erreurs de Discourse : Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
Dernier message sur Discourse à 09:17.
09:22 dans le journal d’erreurs de Discourse : 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 dans le journal d’erreurs de Discourse : Redis::TimeoutError (Connection timed out)
Il y a eu d’autres journaux Discourse similaires jusqu’au moment où j’ai remarqué que le site était en panne vers 11:20.
Lorsque je n’ai pas pu me connecter via SSH, j’ai pris ces captures d’écran depuis le visualiseur de console virtuelle et j’ai redémarré la VM en force :
J’administre des serveurs Linux depuis longtemps, et cette chaîne d’événements ne me semble pas logique. Les journaux de Discourse semblent être une indication assez évidente d’un événement de manque de mémoire (out-of-memory), et la console virtuelle confirme qu’un composant de mon serveur de messagerie dockerisé sur la même VM a été éliminé par le tueur OOM (OOM killer). Mais il n’y a aucune trace de cette action OOM dans journalctl, qui a apparemment cessé de fonctionner bien avant que les autres systèmes ne commencent à échouer. L’événement apparemment premier à 05:00:22 mentionne le processus postmaster (de PostgreSQL dans le conteneur de l’application Discourse) plusieurs fois, mais la base de données n’a pas complètement planté avant au moins 09:17, date à laquelle un message a été envoyé avec succès sur Discourse.
Actuellement, après avoir fonctionné toute la journée, le système affiche une utilisation normale de la mémoire, c’est généralement là qu’elle se situe :
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
La seule chose légèrement inhabituelle dans ma configuration est que l’espace swap est en fait via Zram au lieu d’un fichier swap ou d’une partition swap. J’utilise Zram depuis des années et je n’ai jamais eu de problème. J’ai également installé la VM à partir de zéro avec l’ISO d’installation Debian afin d’avoir un système de fichiers racine XFS au lieu du EXT4 standard que les images Debian du fournisseur cloud utilisent. L’hôte est Hetzner, et après mon installation initiale de Discourse sur Clear Linux, j’ai créé une VM différente pour la migration vers Debian, donc je suis probablement sur un nœud d’hyperviseur différent et je ne pense pas qu’il s’agisse d’un problème matériel. Je me demande donc s’il s’agissait simplement d’un problème de manque de mémoire, ou si j’ai trouvé un cas limite dans la combinaison du noyau 6.1 + Zram + XFS + KVM/virtio ? J’apprécierais toute information que vous pourriez avoir.
Postgres a besoin de plus de mémoire. Vous pouvez ajuster ces paramètres de mémoire et peut-être ajouter de la RAM, mais je pense que vous devrez modifier vos allocations de mémoire postgres.
Votre serveur Hetzner utilise-t-il de la RAM ECC ?
Ma première réaction ici est un problème matériel… puis une recherche rapide sur le web montre des publications à leur sujet utilisant du matériel de qualité de bureau.
Hmm. I would tend to agree, except for the kernel errors that started first. The VM had been running since 06/Jul without a single kernel oops until this morning. Here’s the full output of that instant. Notice the page_fault_oops and handle_mm_fault and xfs_filemap_map_pages stuff:
I kind of think the same thing, except that this is somewhat of a repeat issue, feels slightly not random enough. I suspect that Hetzner probably doesn’t use ECC RAM, that’s probably how they can offer so much for the price. Even their dedicated servers apparently don’t/didn’t have ECC. But even so Hetzner is generally regarded as quite reliable in terms of their infrastructure.
Mon intuition est la suivante . Essayez de vous débarrasser de Zram et XFS (un par un) et voyez ce qui se passe. Zram est mon premier suspect. Discourse devrait fonctionner correctement avec un swap régulier et ext4. Ces optimisations sont peut-être amusantes, mais elles augmentent actuellement la complexité de votre installation. Une fois que votre instance fonctionne correctement, vous pouvez les réintroduire une par une et voir ce qui casse.
En règle générale, essayez de vous en tenir d’abord à une installation recommandée, puis ajoutez vos propres astuces.
Merci pour votre réponse. Je pense que je vais essayer de désactiver Zram et d’ajouter un fichier swap de 2 Go. Le changement de système de fichiers nécessiterait de reconstruire complètement la VM avec une nouvelle installation de Debian, et XFS ne devrait vraiment causer aucun problème.
J’aimerais que ce soit vrai, mais ne me lancez pas sur XFS. J’ai perdu au moins 200 heures de ma vie au cours de la dernière décennie à cause de XFS qui causait des problèmes de mémoire dans le noyau.
Eh bien, il semble que @RGJ ait eu absolument raison à propos de XFS. Merci de m’avoir mis sur la bonne voie. (J’utilise principalement XFS comme premier choix depuis environ 2002, donc j’ai toujours tenu pour acquis qu’il était extrêmement fiable, ce qu’il est en tant que système de fichiers, mais apparemment il y a des bugs liés à la mémoire.) Le même problème s’est produit après avoir désactivé zRAM, puis Debian a publié une mise à jour pour le noyau 6.1 qui inclut un correctif pour les plantages avec XFS :
Depuis que j’ai installé le noyau 6.1.0-13, le serveur est opérationnel depuis 42 jours sans aucun problème.
. Essayez de vous débarrasser de Zram et XFS (un par un) et voyez ce qui se passe. Zram est mon premier suspect. Discourse devrait fonctionner correctement avec un swap régulier et ext4. Ces optimisations sont peut-être amusantes, mais elles augmentent actuellement la complexité de votre installation. Une fois que votre instance fonctionne correctement, vous pouvez les réintroduire une par une et voir ce qui casse.