Bonjour à tous, nous essayons de résoudre les problèmes que rencontre notre installation Discourse ces derniers jours.
Nous utilisons un VPS cloud Contabo, 8 cœurs/32 Go/NVMe, pour une base d’utilisateurs d’environ 150 personnes ; nous avons eu peu de problèmes au cours des deux dernières années et demie.
Depuis le week-end dernier, l’instance connaît des moments de quasi-inutilisabilité, en raison d’une utilisation du CPU anormalement élevée.
Pour dépanner cette situation, nous avons mis le forum en mode Lecture Seule hier. J’ai quelques graphiques Grafana montrant notre situation - les trois marqueurs indiquent où nous avons activé la Lecture Seule, quand nous avons redémarré le conteneur et quand nous avons désactivé la Lecture Seule.
Comme vous pouvez le voir, l’utilisation est assez élevée. Cela a commencé il y a quelques jours, il y a donc une sorte de problème que nous n’avons pas encore correctement identifié.
La chose inhabituelle que nous avons remarquée est que notre hébergeur redémarre le VPS pendant la nuit du dimanche, et que le week-end dernier, la base de données n’a pas réussi à terminer une ou plusieurs transactions.
Nous pensons que cela a pu créer des incohérences dans une sorte de processus interne de Discourse, et que cette incohérence se bat contre l’activité des utilisateurs - mais ce n’est qu’une hypothèse, ici.
Après avoir demandé à l’assistant IA avant d’ouvrir un nouveau fil de discussion, je peux ajouter que Sidekiq présente quelques processus aberrants :
Jobs::ProcessBadgeBacklog prend environ 2 à 5 secondes
le dernier DestroyOldDeletionStubs a pris 475 secondes.
le dernier DirectoryRefreshDaily a pris 580 secondes.
le dernier TopRefreshToday a pris 18 secondes.
Donc, la question est : qu’est-ce qui pourrait causer ce genre de situation, avec la base d’utilisateurs et le matériel que nous utilisons ?
Y a-t-il quelque chose de plus spécifique que nous devrions examiner ?
Je pense que notre base d’utilisateurs ne devrait pas justifier des situations d’urgence, mais je ne suis pas attaché à aucune des opinions que nous avons eues jusqu’à présent, et nous serions très reconnaissants pour des indications sur ce que nous pourrions examiner d’autre.
Je note, pendant les périodes de forte activité, beaucoup de temps noyau système, ce qui signifie souvent de la pagination. Vous pouvez toujours exécuter vmstat 5 5
pour obtenir un instantané de la façon dont le système de mémoire virtuelle gère la situation.
procs -----------memory---------- —swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
8 8 1328504 492436 94200 25567584 23 25 6248 521 6 6 27 12 50 12 0
6 9 1333112 486980 94248 25407008 6 874 48655 2216 6361 8527 34 22 8 36 0
4 7 1336952 519160 94424 25402680 50 1189 37687 2834 6645 9464 39 20 10 31 0
6 5 1340792 557916 92900 25426764 118 921 41032 2745 7407 10996 41 19 10 29 0
11 8 1350228 508828 90920 25314032 11 1842 46922 3582 5351 7645 47 20 8 25 0
This is definitely a memory issue: I’m seeing some huge queries here.
The question, now, becomes “what is causing these queries to be so big”, because it happened suddenly and I assume our case (150 users, 1000 posts per day) should not be having issues with this amount of memory.
Am I wrong in assuming this?
Il semble qu’il y ait un tas de processus postgres inactifs qui consomment beaucoup de mémoire, je pense.
Combien de mémoire avez-vous alloué à postgres dans votre fichier app.yml ? Avez-vous modifié les valeurs par défaut ?
De plus, Postgres 13 n’est plus pris en charge depuis un an. Vous devez vraiment effectuer une mise à niveau. Je ne pensais pas que Discourse fonctionnerait avec PG13 – quelle version de Discourse utilisez-vous ?
Cela ne me semble pas être un problème de mémoire : seules environ 6 Go sont utilisées par les applications. Il y a beaucoup de lecture en cours, ce qui, à mon avis (en plus de sidekiq étant occupé), signifie peut-être que postgres lit beaucoup de données anciennes depuis le disque, peut-être pour effectuer des tâches de statistiques. Si la base de données ne tient pas dans la RAM, elle risque d’effectuer beaucoup de lectures si ces données plus anciennes sont consultées. C’est ce que cela suggère.
Je regarderais d’abord sidekiq - je parie qu’il est occupé à exécuter des mises à jour. Vérifiez l’URL /sidekiq lorsque vous êtes connecté en tant qu’administrateur pour voir ce qu’il fait. Cela vous montrera probablement des tâches de mise à jour de longue durée.
Vous pouvez également, sur le serveur SQL :
SELECT pid, application_name, query
FROM pg_stat_activity
WHERE state IS NOT NULL
AND state != 'idle';
pour voir quelles requêtes sont en cours d’exécution et ce qui les appelle. Cela vous donnera un indice sur ce qui cause la charge.
Avez-vous activé les en-têtes de performance ? Vous pouvez les activer et les capturer dans les journaux pour savoir combien de temps Discourse passe sur chaque partie.
Le processus swapd du noyau a accumulé beaucoup de temps. Il est tout à fait possible que l’activité de pagination n’ait pas été capturée par l’exécution courte de vmstat.
Il me semble qu’il y a beaucoup de processus postgres utilisant plus ou moins 20% de la RAM. Trop de processus compte tenu de la RAM disponible ?? Vérifier la configuration de postgresql serait sage.
Mais un redémarrage serait également sage avant de procéder à une nouvelle mesure.
Comme les pourcentages de mémoire s’additionnent pour représenter beaucoup trop, il doit y avoir un partage qui n’est pas visible. Néanmoins, cela ressemble à beaucoup de gros processus.
La situation s’est améliorée.
Nous étions sur la version 3.6.0, PostgreSQL 13 fonctionnait sans problème apparent - jusqu’à présent.
Nous avons reporté la mise à niveau vers la version 15 car nous n’avions pas assez d’espace libre sur le VPS, nous avions besoin de 150 Go étant donné la taille de notre base de données.
Nous avons purgé ce que nous considérions comme des données inutiles - données de suivi et données de recherche entre autres -, effectué une maintenance de routine sur la base de données (VACUUM, par exemple), mis à niveau vers PSQL15, et mis à niveau Discourse également, vers la version 2026.2.
Nous ne savons pas ce qui a exactement résolu le problème, mais nous allons bien maintenant.
La situation semble stable maintenant.
Je vais surveiller les métriques d’utilisation encore quelques jours.
Une autre mise à jour, après quelques jours d’utilisation normale.
Après le pic initial - je me demande ce qui se passait et j’avais peur que nous n’ayons pas été plus près d’une solution - quelque chose a fonctionné. Nous ne savons pas si c’était l’élagage des données, la mise à jour vers PSQL15 ou la mise à jour vers Discourse 2026.1.0, mais au moins le problème est résolu pour l’instant.
Salut encore, je mets à jour le fil de discussion parce qu’il s’est passé quelque chose d’inhabituel, et j’aimerais avoir des indications sur la façon de comprendre ce qui se passe et de résoudre ces situations.
Comme je l’ai dit, tout se passait bien ces derniers jours.
Puis quelque chose arrive.
(graphique sur 4 jours)
L’augmentation du CPU n’est pas arrivée par hasard, elle est liée à ce redémarrage impromptu :
(graphique sur 24 heures)
Maintenant, notre service d’hébergement commence à nous décevoir, mais des interruptions de service aléatoires peuvent arriver, et déplacer toute l’installation représenterait beaucoup de travail, nous allons donc tolérer la situation pour l’instant.
J’aimerais aussi partager le graphique sur 30 jours, pour montrer à quel point ce plateau aléatoire est énorme
La question est, que suggérez-vous dans ces cas ? Parce qu’essayer d’analyser Sidekiq me dit, au mieux, que de nombreux recalculs de statistiques accaparent les ressources (c’est-à-dire Jobs::DestroyOldDeletionStubs - 419 secondes ; Jobs::AboutStats - 472 secondes ; Jobs::EnsureDbConsistency 2083 secondes ; Jobs::TopRefreshOlder - 2727 secondes), et que les redémarrages inattendus sont un gros problème.
Mais j’espérais que les conséquences des redémarrages aléatoires se résoudraient d’elles-mêmes en un nombre raisonnable d’heures, alors qu’il semble qu’elles aggravent simplement le statu quo actuel.
D’après mon expérience, ce type de comportement du processeur est plus probablement causé par une infection ou un problème de sécurité du serveur, plutôt que par Discourse lui-même.
J’ai déjà rencontré une situation similaire, et le remplacement du serveur a fini par résoudre le problème.
À mon avis, la migration est probablement nécessaire. Vous pourriez configurer un nouveau serveur et y installer Discourse pour tester — si tout fonctionne normalement, il y a de fortes chances que le problème soit causé par une infection ou un problème de sécurité du serveur.
De plus, puis-je demander si ce serveur a été régulièrement mis à jour ? Cela fait-il longtemps depuis la dernière mise à niveau ?
Honnêtement, ce n’était pas sur ma carte de bingo.
Nous sommes sur Ubuntu Server 22, il y a quelques mises à jour mineures à faire, cela ne fera pas de mal de forcer une mise à niveau de toute façon.
Voyons ce qui se passe.
Mon inquiétude est que la mise à niveau maintenant pourrait ne pas éliminer complètement tout logiciel malveillant déjà présent dans le système.
Je recommanderais toujours de configurer un nouveau serveur et d’y installer Discourse pour les tests. Si tout semble bon, vous pourrez alors migrer et résoudre le problème d’un seul coup.
Il ne semble y avoir aucun logiciel malveillant, nous avons exécuté chrootkit et rkhunter et il n’y a pas de rootkits, aucun logiciel malveillant.
À titre d’information, le serveur n’est pas un laboratoire personnel (homelab), c’est un VPS Contabo, et il n’héberge qu’un conteneur Discourse et un conteneur Prometheus/Grafana.
La situation s’est même aggravée depuis hier, cependant.
(Graphique sur 12h)
Existe-t-il une sorte de configuration à « faible intensité » concernant le recalcul des statistiques ?
Je regarde toujours Sidekiq et je ne vois aucun modèle spécifique dans les noms des tâches (job names), il semble que tout processus risque de prendre plus de 2 secondes.
Je commence à penser que regarder le planificateur (scheduler) n’est pas très utile.
Aquele meu servidor também hospedava apenas um site, assim como a sua situação. Eu também não consegui descobrir o problema sozinho na época, então optei por resolvê-lo mudando para um novo servidor.
Acho que se você não for realmente um especialista nesta área, a solução mais eficiente e direta é simplesmente mudar para um novo servidor. Se você se considera um especialista em sistemas, então pode dedicar seu tempo para analisar este servidor e corrigir o problema adequadamente.
Malheureusement, ce n’est pas une ligne de conduite que nous pouvons adopter pour le moment. Ce n’est pas exclu, mais si nous choisissons de procéder à cela, cela signifiera que nous considérerons également d’autres options d’hébergement - un choix qui prendra du temps.
Quoi qu’il en soit, nous essayons de comprendre une autre métrique clé. Grafana et Prometheus fonctionnent correctement, alors qu’est-ce qui pourrait expliquer ceci :
(Graphique sur 7 jours)
Au début, j’ai dit : « Hmm, cela semble élevé ». Ensuite, on m’a dit d’aller regarder le graphique sur 30 jours…
(Graphique sur 30 jours)
Les marqueurs se situent autour de la première fois où nous avons mis le forum hors ligne pour une mise à jour vers la version 2026.1.0.
Il me semble que le nombre d’erreurs HTTP est excessif. Je crois que c’est un symptôme, clairement, qui pourrait être lié aux nombreux 502 que les utilisateurs peuvent rencontrer lors de pics d’utilisation du CPU, mais cela pourrait-il être lié à un autre sous-processus qui rencontre/crée des problèmes ? Je trouve étrange que nous soyons passés d’une moyenne d’erreurs si basse à la situation actuelle.
