Cela pourrait-il indiquer que UNICORN_WORKERS est réglé trop haut/bas ?
Le serveur dispose de 64 Go de RAM (il affiche généralement environ 40 Go de libre) et de 6 cœurs. Il y a 4 instances Discourse sur le serveur, chacune réglée sur UNICORN_WORKERS: 8.
Des idées ou des conseils sur la cause ou sur quoi essayer ? (L’un des forums est en mode lecture seule et ne reçoit pas beaucoup de trafic, devrait-il être configuré pour avoir moins de workers ?)
Merci pour vos réponses à tous. Je ne suis pas sûr de l’endroit où j’ai lu cela maintenant, mais j’ai toujours pensé que nous devions définir 2 workers par cœur. J’ai maintenant réduit le nombre de workers par forum, en allouant plus aux forums les plus fréquentés et moins à ceux qui le sont moins. Je vais surveiller les choses au cours de la semaine prochaine et je ferai un compte rendu si cela n’a pas aidé.
Dans votre cas, vous n’allouez pas deux workers par cœur. Vous avez six cœurs, ce qui signifierait douze workers, mais vous avez quatre instances utilisant chacune huit workers, soit 32 au total.
Oui… J’ai ajusté pour que le nombre total de workers ne soit pas supérieur à deux fois le nombre de cœurs, bien que je me demande toujours : quel est le conseil correct/standard, ce que vous avez dit ou ce qui était dans le post de Nate, où il cite Jeff disant 1 worker par cœur ?
D’après mes propres expériences, 1 worker par cœur entraîne des timeouts (mais réduit la charge du serveur), plus de workers entraînent de meilleures performances mais une charge plus élevée (qui sur mon serveur reste dans une plage acceptable).
Regardez discourse-setup, qui gère la mise à l’échelle des nouvelles installations aujourd’hui :
# UNICORN_WORKERS : 2 * Go pour 2 Go ou moins, ou 2 * cœurs CPU, max 8
si [ "$avail_gb" -le "2" ]
alors
unicorn_workers=$(( 2 * $avail_gb ))
sinon
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
Cette deuxième déclaration, utilisant le double du nombre de cœurs disponibles, est la valeur par défaut sur les systèmes disposant de plus de 2 Go de RAM. Il semble que votre problème soit davantage dû à une lutte entre vos instances (ressources hôtes) qu’à un problème de discourse.
Je vois la même chose après ma dernière mise à niveau, qui a eu lieu un jour après l’OP, donc je ne pense pas que cela ait quoi que ce soit à voir avec le nombre de workers unicorn. Le processus unicorn.conf.r* est suspect, car la publication originale de ce sujet est le seul résultat pour ce terme sur le web entier. Je pense que unicorn.conf.rb serait plus normal.
L’augmentation s’est produite exactement lors de ma dernière mise à niveau, il y a 4 jours. Notez que l’OP a posté il y a 5 jours. Quelque chose a changé dans Discourse.
J’ai utilisé le même nombre de workers unicorn sur la même instance pendant plusieurs années, et je n’ai rien changé - j’ai simplement reconstruit en 3.4.0.beta4-dev.
Je viens de passer à la dernière version de Discourse et je n’ai plus vu de unicorn.conf.r* (maintenant, tout ce qui tourne autour de 80% d’utilisation du CPU est juste ruby, bien que cela semble moins fréquent). Les charges sont à peu près les mêmes (bien que plus faibles qu’après mes ajustements de workers).
Avez-vous mis à jour vers la dernière version ? Quel type de matériel utilisez-vous et à quel point votre forum est-il occupé ?
Oui, je suis à la version 3.4.0.beta4-dev. C’est ce qui a déclenché l’utilisation élevée du processeur. Rien d’autre n’a changé.
8 Go de RAM, 2 vCPU, SSD de 160 Go avec beaucoup d’espace.
J’ai posté l’utilisation du processeur ci-dessus pour mon site de production, qui compte environ 30 utilisateurs en ligne à la fois. Mais j’ai un site de test avec le même problème et il n’y a absolument aucun trafic ni aucun plugin. Utilisation du processeur avant et après la mise à jour (les pics sont des sauvegardes quotidiennes) :
Je ne suis pas sûr que nos situations soient liées, Mark. Je pense que dans mon cas, ce que Stephen a dit a joué un rôle important :
J’ai récemment déplacé deux autres instances sur le même serveur et j’avais en fait oublié que les workers unicorn étaient réglés sur 8 car nous étions auparavant sur un serveur avec plus de cœurs (mais il avait ses propres problèmes, d’où notre retour à un Xeon qui avait moins de cœurs mais fonctionnait mieux dans l’ensemble).
J’ai donc constaté qu’en réduisant les workers unicorn sur ce serveur, la charge diminuait, mais cela entraînait des timeouts. En les augmentant, les timeouts étaient éliminés, mais la charge était plus élevée, bien que toujours dans une plage acceptable. Je pense que je pourrais augmenter les workers et nous pourrions toujours gérer la charge accrue, mais ce que nous avons maintenant est bien pour le moment.
Cela dit, j’avais déplacé les instances sur le même serveur et il fonctionnait dans les limites de ce que j’attendais (la charge a augmenté mais pas énormément) et j’ai eu l’impression qu’une mise à jour entraînait des charges plus élevées… cependant, je ne peux pas en être sûr, et nous devons garder à l’esprit qu’avec l’ajout de fonctionnalités à Discourse, il peut nécessiter du matériel plus puissant ou donner l’impression d’être parfois ‘plus lent’ (j’avais des instances Discourse sur d’anciennes versions et elles semblaient nettement plus réactives - bien qu’elles n’aient bien sûr pas toutes les fonctionnalités des versions plus récentes).
Cela dit aussi, je pense que les charges ont en fait légèrement diminué depuis la dernière mise à jour de Discourse (avec PG 15).
Je ne sais pas quoi vous suggérer, Mark - peut-être jouer avec les workers et d’autres paramètres aussi ? Comme db_shared_buffers et db_work_mem ? Peut-être lancer un fil de discussion dédié du genre “Utilisation élevée du CPU après la mise à jour - mon instance a-t-elle besoin de réglages de performance ?” Ou quelque chose comme ça
J’ai mis à niveau ce soir et j’ai immédiatement constaté une différence d’utilisation du processeur sur mon site. Voici un graphique avant, pendant et après la mise à niveau. Cela représente une durée d’une heure.
Voici les résultats 15 heures après la mise à niveau. Le pourcentage d’utilisation du processeur a considérablement augmenté de 3X. Le facteur de charge a augmenté de 4x.
Il semble donc que mon problème n’était pas les workers unicorn après tout - après la mise à jour de @sam suite au fil de discussion de @LotusJeff, les charges du serveur sont revenues à ce qu’elles étaient (moins de la moitié de ce qu’elles avaient atteint)…
Je ne m’en serais probablement pas rendu compte si je n’avais pas surveillé le serveur après y avoir récemment déplacé les deux autres forums. Je me demande combien de personnes cela a affectées sans même qu’elles s’en rendent compte ?
L’équipe Discourse a-t-elle mis en place des mesures pour les alerter de problèmes comme celui-ci ? Peut-être un programme de bénévolat que les administrateurs peuvent mettre en place pour des sujets spécifiques, par exemple, « Envoyer les charges du serveur à Discourse XX heures/jours/semaines avant/après une mise à niveau ». Ou mieux encore, suivre cela localement, puis alerter les administrateurs lorsque des augmentations de charge du serveur sont remarquées après les mises à niveau, ce que nous pourrions alors publier ici si nécessaire.
Je n’aurais probablement pas remarqué l’impact, mais je surveille le serveur de près car nous avons migré vers Discourse il y a environ 2 semaines. Je suis en plein travail pour effectuer diverses validations post-migration (sauvegarde, etc.). Après quelques mois, je n’aurais jamais remarqué l’impact.
J’espère que Discourse a un test de charge quotidien. Dans ma vie antérieure, j’avais un serveur qui était reconstruit quotidiennement avec le code validé. Il y avait des utilisateurs simulés utilisant le serveur toute la journée. Nous mesurions les indicateurs de performance clés du point de vue de l’utilisateur et du serveur. Cela nous a permis de détecter de manière proactive les fuites de mémoire, le code inefficace et les changements inattendus dans l’expérience utilisateur.
Je dois quand même féliciter Sam et l’équipe. Venant du monde de phpBB, où une telle chose prendrait des décennies à résoudre et à remédier, j’ai trouvé la réponse rapide formidable. (Même si cela signifiait rester éveillé jusqu’à 2h du matin CT par rapport à l’heure de Sydney.)
