Alors toutes les affirmations selon lesquelles le UNICORN WORKER devrait être 2*vCPU sont fausses ?
Mon serveur est un Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32Go de RAM
Combien de UNICORN WORKER dois-je configurer ?
8 ? ou 48 ?
Mon site compte plus de 7 000 utilisateurs et environ 1 000 utilisateurs actifs par jour. Les utilisateurs envoient 3 000 à 7 000 messages par jour. Notre communauté a 120 000 à 200 000 pages vues par jour, y compris les robots d’exploration et les utilisateurs anonymes.
Cela dépend de nombreux facteurs. Par exemple, la taille de votre base de données par rapport à votre RAM, le ratio de trafic connecté par rapport au trafic anonyme, si vous avez des plugins qui maintiennent votre file d’attente Sidekiq plus occupée, si vous exécutez YJIT, etc.
Ce qui est simple, c’est de regarder les données MiniProfiler pendant votre heure de pointe et de parcourir le forum pour voir si les performances sont moindres et identifier le goulot d’étranglement.
Comme ce CPU est ancien, je commencerais avec plus que le nombre habituel d’employés Unicorn, car chaque requête prendra plus de temps que d’habitude. Mais si vous exécutez PostgreSQL et Redis sur le même serveur, vous ne pouvez pas les priver en exécutant trop d’employés.
Essayez de commencer avec 16 employés et évaluez les performances du site.
Existe-t-il une description simple et conviviale de ce que font les workers Unicorn ? J’ai l’impression que chaque requête de page utilisateur doit passer par un worker Unicorn pour être traitée. Si vous n’en avez pas assez, l’utilisateur doit attendre. Si vous en avez trop… eh bien, peut-être que cela vous coûte un peu de RAM ?
Ce sont les serveurs web de l’application.
1 « J'aime »
Il semble que votre CPU vieux de 10 ans montre son âge. Augmenter le nombre de workers Unicorn vous permettra de servir plus d’utilisateurs simultanément, mais n’accélérera pas une requête individuelle.
Pouvez-vous essayer d’activer YJIT ?
3 « J'aime »
Avec votre matériel, je m’attendrais à obtenir un temps moyen de connexion/dernier temps d’environ 150 ms pour l’application, 80 ms pour SQL.
Je commencerais avec 12 workers et je verrais comment cela se comporte. La meilleure chose que vous puissiez faire est de suivre les métriques ; si vous voulez savoir si vous devriez ajouter plus de workers, vérifiez si les requêtes sont mises en file d’attente en attendant les workers de l’application.
Suivez-vous les métriques que Discourse lui-même exporte via l’exportateur Prometheus ? Celles-ci vous donneront une bonne vue d’ensemble des performances de l’instance.
Quels sont les chiffres de performance pour les utilisateurs anonymes et réguliers (pas administrateurs) ?
5 « J'aime »
Il y a de nombreux méga-sujets dans notre Discourse, et le plus grand est déjà dans la douzième section.
Vues des réponses
1 « J'aime »
(/arrête de rire, se connecte au fournisseur d’hébergement … )
wow, ce n’est pas la valeur par défaut maintenant ??
edit : ah bien sûr, vous avez peut-être compilé avec un ancien app.yml et vous n’avez pas mis à jour depuis
1 « J'aime »
C’est le cas dans notre hébergement, mais il est un peu difficile d’en faire un défaut car les gens peuvent fonctionner dans des scénarios de contrainte de RAM…
Cela dit, notre build JS utilise tellement plus de RAM que Discourse lui-même, que l’on pourrait dire que quiconque peut construire les actifs JS a beaucoup de RAM à dépenser :langue_tirée:
1 « J'aime »
Dans ces images, combien d’ouvriers avez-vous configurés ?
Je dirais que vous devriez
- Augmenter un peu les ouvriers, car vous avez une petite file d’attente
- Activer YJIT, car votre temps web est assez lent
Il ne reste que 8 travailleurs, et YJIT est déjà activé.
Combien de travailleurs dois-je augmenter ?
Au fait, voici ce que Falco regardait pour faire cette recommandation :
Je passerais de 8 à 12. Cela vous donnera une marge de manœuvre et devrait vider ces files d’attente.
Cette forte pointe, d’ailleurs, indique que les autres requêtes attendent… quelque chose, probablement un verrou commun. Peut-être un méga-sujet.
Si vous pouvez également obtenir des métriques d’utilisation de postgres, ce serait utile.
les méga-sujets sont un point faible, voir Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Envisagez de les diviser ou d’utiliser le chat à la place (je vois que votre plus grand sujet avec 8,9k réponses est explicitement une salle de chat).
La culture de discussion de notre communauté est celle des mégatopiques, qui s’est formée avant même que nous commencions à utiliser Discourse, et le chat manque des fonctionnalités de spoilers floutés et de détails cachés.
1 « J'aime »
Comment faire
Nous utilisons GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus, bien que je ne sois pas sûr qu’il existe des guides sur meta concernant sa configuration.
Cependant, étant donné que vous semblez déjà avoir configuré Prometheus, on dirait que vous savez ce que vous faites.
maintenant la RAM du serveur est de 16/32 Go, UNICORN_WORKERS : 12, db_shared_buffers : « 4096 Mo »
Comme il reste de la RAM disponible et peu de requêtes web mises en file d’attente, j’ai augmenté le nombre de UNICORN_WORKERS à 24. Cet après-midi, le serveur s’est soudainement arrêté et après son redémarrage, les utilisateurs ont afflué immédiatement. Cela a entraîné un très faible nombre de requêtes web actives et un grand nombre de requêtes mises en file d’attente. Il y a quelques jours, nous avions observé que 24 UNICORN_WORKERS pouvaient gérer plus de 150 requêtes web actives, mais seulement 30 requêtes web actives cet après-midi. C’est parce que nous venons de changer de domaine et que de nombreux articles sont en cours de re-cuisson par sidekiq. Cela a exercé une forte pression sur le serveur. Que devrions-nous faire ?
