Nous avons rétabli toutes les valeurs modifiées par défaut et mis à jour vers la version 2.6.0 bêta4. Des jeux sont prévus jeudi et vendredi, nous aurons donc une bonne couverture de tests plus tard cette semaine.
Malheureusement, la correction ne résout pas le problème. Nous avions un jeu modérément actif avec 600 messages. Plusieurs gelés ont été observés lors de mes propres tests, ainsi que par nos membres. Ils correspondent à des événements du jeu, c’est-à-dire des pics d’activité.
- L’utilisation du CPU restait bien dans les limites, culminant autour de 60 % avec une charge moyenne d’environ 30 %.
- C’est clairement un problème côté client. Lorsque le sujet de discussion se fige, si vous allez sur la page d’accueil, vous verrez le nombre de messages non lus. En revenant au sujet, les messages redeviennent visibles.
Ce qui me laisse perplexe et qui n’est pas abordé dans ce sujet, c’est ce qui a changé depuis la version 2.3, qui ne présentait pas ce problème.
Les mises à jour majeures 2.4 et 2.5 ont eu lieu pendant notre intersaison (prolongée par la COVID), donc personne n’a remarqué quoi que ce soit, mais les gelés sont apparus immédiatement lors du tout premier match d’exhibition de la pré-saison.
Y a-t-il des astuces de paramètres que nous pourrions essayer pour demain ? Ce sera un derby intense et un match à l’extérieur, donc la communauté sera en feu.
Dans notre cas, désactiver le plugin Who’s Online et désactiver le fichier de limitation du taux (et j’ai lu qu’il y avait eu des améliorations avec la bêta plus récente) a semblé faire l’affaire pour nous.
Nous avons maintenant aussi des matchs de football de temps en temps avec 300 utilisateurs ou un peu plus qui cliquent et écrivent tous dans le même sujet en même temps, et cela a semblé bien mieux fonctionner lors du dernier match.
Êtes-vous sur la dernière version, avec la correction récente ?
S’il vous plaît, s’il vous plaît, mettez à jour pour que les tests passent. J’ai beaucoup affiné les choses depuis la bêta.
Oui, la dernière version bêta (c’est-à-dire celle des 48 dernières heures).
Mise à jour effectuée. Un rapport suivra.
Malheureusement, toujours pas de succès. Certes, la partie était intense avec 950 messages. J’ai surveillé GAnalytics : environ 250 personnes étaient connectées, et 119 ont publié. Comme précédemment, plusieurs gelages ont été observés. Le message-bus a renvoyé quelques erreurs 429, avec les messages « Vous avez effectué cette action trop de fois, veuillez patienter X minutes ».
La charge CPU a atteint un pic d’environ 70 %, et le temps d’attente (wa) était pratiquement nul. Bien que l’activité ait été élevée, nous ne sommes toujours pas en mesure de fournir ce que le matériel serait capable de faire.
Pourriez-vous répondre à une question qui me tracasse : qu’a-t-on implémenté après la version 2.3 qui cause cela, et quel est son objectif ?
L’implémentation reste globalement la même qu’avant, sauf que nous avons désormais des limites de taux globales pour l’application, qui sont configurables. Vous pouvez les augmenter si vous le souhaitez, mais cela pourrait provoquer un effondrement total, je ne sais pas.
Je ne comprends pas ce que vous entendez par « freezes ». Si le système devient trop chargé, il cessera de se mettre à jour, mais la différence est que vous n’avez plus besoin de rafraîchir le navigateur pour corriger la page : elle se rétablira automatiquement dès que le serveur aura de la capacité.
Un peu flou ici : vos utilisateurs constatent-ils aucune amélioration après mes modifications ?
Votre serveur dispose-t-il de beaucoup de RAM libre ? Si oui, ajoutez des workers Unicorn.
Que contient le paramètre db_shared_buffers ? Nous avons connu beaucoup de comportements « instables » au début (certains sujets « consomment » beaucoup de ressources, surtout lorsqu’ils sont très actifs) avec simplement les 25 % recommandés de la RAM totale. Lorsque nous l’avons augmenté à 16 Go (sur 32 Go), toute cette instabilité a disparu… et plus récemment, la situation s’est encore améliorée grâce aux dernières modifications.
D’accord, ce phénomène est difficile à surveiller dans un environnement de production (salons de discussion de jeux), car chaque jeu est différent : nombre d’événements critiques, adversaire, charge émotionnelle, etc.
Le problème, de notre point de vue, c’est que notre capacité maximale de service a diminué depuis la version 2.3. C’est là le point clé. Chaque serveur a ses limites, mais nous obtenons maintenant moins de nos serveurs qu’en mars, lorsque nous exécutions la version 2.3. Selon une surveillance approximative du backend, le serveur ne peut pas atteindre 100 % de charge ou de capacité.
Ce que voient les utilisateurs finaux, c’est que le flux de discussion s’arrête simplement, sans aucune indication dans l’interface utilisateur sur ce qui se passe. Cela crée de la confusion.
Je suis assez certain que les modifications validées par les tests ont amélioré la situation, mais les performances ou la production maximale restent nettement inférieures à celles de la version 2.3.
Nous disposons d’un VPS avec 6 cœurs rapides et 16 Go de RAM. Les processus Unicorn sont configurés à 12, et les paramètres liés au tampon de la RAM sont aux valeurs par défaut.
Je pense que la meilleure prochaine étape consiste à mettre en place une surveillance historique de votre système afin que nous puissions identifier où se trouve le goulot d’étranglement, car nous avons établi qu’il ne s’agit pas du temps CPU. Il est toujours possible que vous saturiez votre connexion réseau !
ainsi que des métriques serveur plus traditionnelles comme node-exporter.
Si c’est le cas et que vous souhaitez le solliciter davantage :
-
Vous pouvez réduire les limites de débit, ce qui permettra aux utilisateurs d’interagir plus activement avec Discourse. Plus précisément, vous pourriez doubler
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEetDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
Vous pouvez essayer d’ajouter plus de workers Unicorn.
C’est normal temporairement pendant les périodes de surcharge, mais le système devrait automatiquement récupérer dès que la charge diminue.
Mon hypothèse est que tout cela est lié aux limites de débit. Ces limites sont nouvelles et ont été mises en place pour protéger le serveur. Il semble que votre serveur soit protégé par conception.
Nous avons essayé un jeu avec…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…et lorsque les émotions ont commencé à monter au troisième tiers, les choses se sont aggravées. Nous avons atteint les limites de nos serveurs : les utilisateurs étaient constamment déconnectés et le chat du jeu se gelait également.
C’était une belle histoire de succès pendant quatre ans, mais nous sommes maintenant dans une situation très difficile. Passer au niveau supérieur de capacité VPS nous ferait basculer dans la catégorie de prix d’environ 160 €/mois, ce qui est un défi pour un site amateur. Il ne s’agit pas non plus de volumes d’utilisateurs énormes : 116 personnes ont publié plus de 800 messages pendant le jeu.
L’idéologie « ne faites pas de chats » n’est pas adaptée non plus. Sans eux, les réactions émotionnelles se disperseraient dans des sujets plus « sérieux ». Ils constituent un outil important pour canaliser l’énergie émotionnelle de la situation en direct vers un seul sujet, en gardant les sujets plus analytiques propres.
Le mien est un forum de football et j’ai rencontré des défis similaires.
Fondamentalement, ce que j’ai constaté, c’est qu’il s’agissait d’un problème de scalabilité.
Les problèmes se sont manifestés à différents niveaux.
Digital Ocean
1 CPU, 1 Go = 30 à 40 utilisateurs dans une situation de type chat
2 CPU et 2 Go = 70 à 80 utilisateurs dans une situation de type chat
4 CPU et 8 Go = suffisant pour 120 utilisateurs et 1 000 publications en 2 heures. La limite n’a pas été atteinte.
J’essaie différents niveaux de montée en puissance avec Hetzner (site miroir) car c’est moins cher, mais cela ne s’est pas déroulé aussi fluidement que prévu.
Mon expérience jusqu’à présent est la suivante :
3 CPU (puce AMD CPX 21) et 4 Go = difficultés avec 20 utilisateurs
2 CPU (Intel) et 8 Go = aucun problème avec 20 utilisateurs.
Je suis sur le point de tester avec 80 à 100 utilisateurs simultanés dans des conditions de match.
Lorsque j’ai examiné l’utilisation du CPU avec Digital Ocean, même sous stress, l’utilisation du CPU semblait assez faible, inférieure à 50 % à tout moment et à tous les niveaux.
Lorsque j’ai examiné le CPU pour Hetzner avec la puce AMD, j’observais une utilisation médiane du CPU d’environ 60 %, mais toutes les minutes environ, une brève pointe jusqu’à 300 % de l’utilisation du CPU. Cela ne semblait pas se produire avec la puce Intel.
Je ne sais pas ce que cela signifie. Je soupçonne que la surveillance du CPU est meilleure chez Hetzner (capture des pics courts). Mais globalement, l’utilisation du CPU semble bien équilibrée. DO semble, à première vue, mieux gérer les pics, mais je devrais avoir plus d’informations sur Hetzner après ce week-end.
Je devrais également préciser que, lors du test avec Hetzner, le plugin ‘Who’s Online’ n’a apporté aucune différence.
En revanche, le plugin de messages rapides de Discourse semblait être préjudiciable.
Le prochain jeu est prévu pour demain. Nous avons supprimé nos propres correctifs et nous testons avec ceux-ci.
De plus, en guise de tentative très hasardeuse, j’ai augmenté db_shared_buffers de 4 Go (25 %) à 6 Go (37,5 %). J’ai également décommenté la ligne db_work_mem à 40 Mo dans app.yml (c’est d’ailleurs une option très vaguement documentée, tout en étant présentée à l’administrateur comme une sorte d’opportunité d’amélioration).
Je ne m’attends plus à trouver une solution au problème, mais seulement à mieux gérer les dégâts — un ensemble de paramètres ayant le moins d’impact négatif sur l’expérience utilisateur pour les utilisateurs finaux. En attendant, je devrai évaluer les possibilités pour augmenter davantage nos ressources d’hébergement.
Question pour @sam et les autres développeurs.
Comment la taille croissante de la base de données affecte-t-elle ce cas d’usage, où les utilisateurs sollicitent un même sujet pendant plusieurs heures ?
J’ai examiné l’historique des activités de chat des jeux et constaté que nous avions des jeux avec des statistiques énormes en 2017, alors que notre serveur disposait d’une fraction des ressources dont nous disposons aujourd’hui. Nous avions des jeux où le nombre de messages atteignait 1600 pour 165 utilisateurs, et personne ne se plaignait des performances. Aujourd’hui, nous ne pouvons même pas servir la moitié de cela, avec un serveur beaucoup plus puissant.
Vous pourriez essayer de l’augmenter à 80 Mo. Peut-être à la place de l’autre modification.
C’est un point sur lequel nous travaillons activement en permanence.
Lorsque Discourse était nouveau, presque tous les sites disposaient d’une base de données fraîchement créée, ce qui permettait à celle-ci de tenir facilement en mémoire. Aujourd’hui, quelques années plus tard, certains sites ont des bases de données dépassant 100 Go, alors que la taille de la RAM n’est même pas le dixième de cette valeur.
Une mise à jour prévue dans les prochaines semaines est la mise à niveau vers PostgreSQL 13, qui réduira de moitié la taille maximale des objets.
Par ailleurs, la première étape pour déboguer vos problèmes de performance consiste à collecter des données grâce au plugin d’export Prometheus pour Discourse, afin que nous ne soyons pas en train de naviguer à l’aveugle.