ce message apparaît presque constamment depuis ma dernière mise à jour de discourse il y a quelques jours.
Je n’aurais pas ouvert de sujet ici si ce n’était pas pour la raison que… ce n’est pas vrai.
Le message apparaît mais vous pouvez naviguer sur le forum comme si vous étiez connecté, rien n’est vraiment affiché comme si vous ne l’étiez pas.
La vérification des ressources utilisées/disponibles sur l’hôte ne montre pas que la machine est surchargée ou quoi que ce soit de ce genre.
Quelqu’un peut-il m’aider à comprendre comment ce message est déclenché afin que je puisse commencer à enquêter sur ce qui pourrait causer cet avertissement alors que ce n’est pas vraiment le cas ?
Ce message est significatif, le fait que votre système dispose de ressources libres est plus révélateur d’une mauvaise configuration que d’une mauvaise identification.
Combien avez-vous de unicorn_workers ?
En supposant qu’il n’y ait rien d’autre sur l’hôte, en avez-vous alloué 16 (deux par cœur) ?
Si vous utilisez Postgres local, quelles sont vos db_shared_buffers ?
J’ai laissé les paramètres par défaut de la première configuration de ./launcher et c’était 8 workers.
Idem pour db_shared_buffers : 4096 Mo.
Cependant, suite à certains tests, dont vous pouvez lire la raison ici, les workers ont été réduits à 4. Cela n’a eu aucun effet, donc je peux au moins les restaurer à 8.
La raison pour laquelle ce n’est pas 2xCore, c’est qu’il s’agit d’une VM et qu’il s’agit de vCPU en réalité, pas de cœurs réels.
Je vais surveiller l’instance un peu et revenir pour attribuer la solution si c’est le cas, merci @Stephen
Le message concerne les ressources que vous allouez à Discourse, et non les ressources de la VM/de l’hôte.
Définissez db_shared_buffers à 25 % de votre mémoire réservée et 2 processus unicorn par CPU. Un réglage fin peut être nécessaire.
Évidemment, vous devez également gérer les ressources en dehors de la VM si vous estimez que le pool de ressources n’est pas fiable. Presque tout le monde qui utilise Discourse le fait sur une sorte de VPS.
Je ne suis pas un expert en discourse, j’ai donc simplement exécuté le script d’installation comme je me souviens qu’il devrait définir ces paramètres en fonction de la mémoire/CPU disponible.
J’ai restauré les workers tels qu’ils étaient avant certains tests et je vais vérifier à nouveau.
Pour être honnête, nous n’avons eu aucun problème avec ces paramètres, mais cela pourrait aussi être sans rapport ou seulement partiellement lié.
Je garderai à l’esprit votre suggestion de 2 cœurs pour les workers et 25 % de la mémoire réservée pour les buffers partagés de la base de données.
Quand vous parlez de mémoire réservée, parlez-vous de la mémoire réservée par le conteneur en cours d’exécution ? Parce qu’il semble toujours être juste “autant que l’hôte a de disponible”
# db_shared_buffers : 128 Mo pour 1 Go, 256 Mo pour 2 Go, ou 256 Mo * Go, max 4096 Mo
# UNICORN_WORKERS : 2 * Go pour 2 Go ou moins, ou 2 * CPU, max 8
Le terme « max » peut être pris avec un grain de sel, car les grandes communautés en particulier bénéficieront au-delà de ces chiffres.
Donc oui, dans votre cas, il aurait dû spécifier les maximums de 8 workers et 4096 Mo. Si vous réduisez les workers et les buffers partagés disponibles pour Discourse, il atteindra ses limites avant que toutes les ressources de la VM ne soient consommées.
Ce message de @mpalmer est toujours un bon conseil :
Il me semble qu’il est déclenché lorsque les requêtes sont mises en file d’attente trop longtemps - en d’autres termes, les requêtes arrivent plus vite qu’elles ne sont traitées. On pourrait se demander pourquoi tant de requêtes, ou pourquoi un service si lent. Au niveau de Discourse, il existe des paramètres qui sont déjà discutés dans ce fil de discussion et aussi, par exemple, dans Erreur de charge extrême.
Depuis, tout semblait aller bien, mais depuis quelques jours, le forum semble parfois « lent ». Quand je dis lent, je veux dire que les requêtes prennent du temps à être traitées (soumission de réponses, édition, etc.) et je viens de remarquer le même message à nouveau.
Je suis allé vérifier le tableau de bord Grafana que j’ai configuré et j’ai vu que le serveur est à sa limite en termes d’utilisation du CPU.
J’ai essayé de redémarrer l’application, la charge continue d’augmenter du même montant immédiatement après le redémarrage.
Existe-t-il un moyen de voir quel type de processus utilise le plus de ressources ? J’ai essayé de vérifier le tableau de bord Sidekiq, mais il me montre seulement la liste des processus en cours d’exécution/en file d’attente et le temps moyen d’exécution, certains sont lents (prenant des minutes) mais je ne vois rien en cours de traitement ou en échec.
Je mets à jour tout pour éliminer tout problème potentiel qui pourrait survenir en raison d’un problème avec beta5. Sur 3.1.0.beta6 - 6892324767 maintenant.
Pourtant, l’utilisation du processeur est anormalement élevée. Elle fluctue généralement autour de 60 %.
J’ai également redémarré le VPS, juste au cas où il y aurait eu quelque chose d’étrange (peu probable car cela a commencé soudainement hier après 150 jours de fonctionnement), mais non, même comportement.
C’est un processus de licorne qui consomme toutes les ressources CPU. Existe-t-il un moyen d’obtenir plus d’informations sur ce que font ces licornes ?
Pour un aperçu rapide, bien sûr, cela oscille, mais c’est la moyenne pour les travailleurs de licorne en activité, ce qui me semble anormal alors que cela dure depuis la veille :
Votre charge moyenne > 8 sur une machine à 8 vCPU signifie que votre serveur est submergé.
Entre 8 unicorns, de nombreux pids PostgreSQL et tout le reste sur votre serveur, il ne peut pas traiter les requêtes entrantes assez rapidement. Au moins, vous avez beaucoup de mémoire
Il est assez inhabituel que Discourse soit limité par le CPU d’unicorn comme ça. La plupart du temps, j’ai vu cela se produire à cause d’un plugin mal configuré. Pouvez-vous partager votre app.yml ?
Veuillez également partager les résultats de MiniProfiler lors du chargement de votre page d’accueil et d’une page de sujet.
J’ai demandé à l’hébergeur d’enquêter si nous nous faisons voler du temps CPU par d’autres VPS sur leur hôte, car il est vraiment étrange que cela se soit produit si soudainement sans que rien n’ait vraiment changé de notre côté.
J’attends que le support technique revienne avec des résultats.
Merci pour les résultats. Pour référence, la première ligne des statistiques de vmstat n’est pas très utile - les cinq lignes donnent l’image nécessaire.
C’était comme je le pensais à la fin. Un autre VPS a été déployé sur l’hôte et le vidait.
Nous avons été déplacés vers un autre hôte moins de 24 heures après l’ouverture du ticket.
Bravo à Contabo
Je demanderais aux modérateurs de laisser ces dernières réponses ici même si ce n’est pas lié au « discours », car cela peut aider d’autres personnes à trouver d’autres raisons pour lesquelles leur instance pourrait avoir des problèmes.
