Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?
I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?
The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.
I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.
Il y a eu (ou il y a) quelques sujets sur l’optimisation. La plupart des sujets réussis, je pense (à l’exception de celui-ci), fournissent des détails précis sur les ressources disponibles, db_shared_buffers et d’autres paramètres, ainsi que sur les problèmes rencontrés, peut-être avec des sorties de htop ou d’autres outils. Quelle est la taille de votre base de données ? Quel problème rencontrez-vous ? (Vous pourriez vouloir créer un nouveau sujet)
Merci ! Pas de problème pour l’instant. Je remarque juste une utilisation élevée de la mémoire, mais ce n’est pas un forum très fréquenté. J’ai l’habitude de penser de manière proactive et de vérifier quelles ressources sont les plus utilisées. Ceci est juste sur un VPS de 3 Go avec 6 cœurs @ 3,5 GHz. Pas lent, vraiment rapide, mais je vois que l’utilisation de la mémoire pourrait devenir un problème futur et je suis curieux de savoir ce que je peux ajuster.
Je vais lire davantage sur les applications Ruby on Rails en général et sur l’optimisation. Merci encore.
Selon la mesure de « l’utilisation » que vous entendez, cela pourrait être normal. Mais avec 3 Go, il n’y a probablement pas beaucoup de réglages à faire, car si vous avez exécuté ./discourse-setup, ses estimations sont probablement suffisantes.
free -h
total used free shared buff/cache available
Mem: 2.9Gi 1.8Gi 167Mi 100Mi 1.0Gi 895Mi
Swap: 1.0Gi 587Mi 436Mi
Disponible est d’environ 900M. Pas encore de problème. Mais un problème ne m’a pas amené ici. J’aimerais savoir quoi faire si/quand la mémoire disponible devient un problème à l’avenir. Outre l’ajout de plus de mémoire, bien sûr.
À ce niveau, la seule chose à faire sera d’y ajouter plus de RAM. Si vous avez 8 ou 16 Go, il y a quelques choses à faire. Au pire, vous pourriez vouloir ajouter 1 Go de swap supplémentaire, mais vous devriez probablement vous en sortir.
Si vous aviez exécuté ./discourse-setup, il aurait créé un fichier swap de 2 Go. Vous pourriez rencontrer des problèmes lors d’une reconstruction.
ok, j’ai réussi à presque doubler la mémoire disponible en changeant la valeur par défaut de l’installation de : UNICORN_WORKERS: 8
à UNICORN_WORKERS: 4
Ensuite : sudo ./launcher rebuild app
Je suis maintenant en train de configurer la surveillance de PostgreSQL et je verrai ce qui se passe là-bas.
Il y a toujours un moment où une ressource devient un goulot d’étranglement. Mais votre serveur me semble actuellement largement surdimensionné.
Vous utiliserez plus de mémoire lorsque vous aurez plus de processus Unicorn.
Vous aurez besoin de plus de processus Unicorn lorsque vous aurez plus de trafic sur votre site.
Je vois tous les processus Unicorn utiliser 0,0 % de CPU et seul worker[0] semble réellement faire quelque chose.
Vous avez réduit la mémoire en exécutant moins d’Unicorns. C’est bien, car vous ne sembliez pas les utiliser de toute façon. Mais la mémoire disponible est en fait une mauvaise chose. Vous optimisez pour la mauvaise variable.
La mémoire inutilisée ne vous apporte rien. Cela signifie que vous payez pour quelque chose que vous n’utilisez pas de toute façon. Si vous avez 2 Go disponibles en permanence*, vous pourriez réduire la taille de votre serveur et économiser de l’argent.
*) La reconstruction de Discourse consommera plus de mémoire, vous devez donc vérifier la quantité de mémoire disponible pendant la reconstruction. En pratique, ne descendez pas en dessous de 2 Go au total et/ou assurez-vous d’avoir suffisamment de swap, comme Pfaffman l’a déjà dit.
Pas correct. La mémoire « libre » qui ne fait rien est mauvaise. Mais la mémoire « disponible » est la mémoire utilisée par le système qui peut être facilement libérée, c’est une bonne chose.
Ou officiellement :
Mémoire disponible : Estimation de la quantité de mémoire disponible pour le démarrage de nouvelles applications, sans échange.
Source : man free
Comme le montre la capture d’écran ci-dessous, la mémoire libre est pratiquement inchangée. Donc, presque toute la mémoire du système est utilisée. Cependant, le système échangera moins maintenant car il y a plus de mémoire disponible qui peut être libérée si nécessaire.
Je pense que mauvais signifie ici qu’elle coûte, mais ne rapporte rien. C’est une façon de penser assez courante, car quand on a besoin de plus de ressources, cela coûte aussi plus cher — et la RAM est un élément coûteux dans cette équation.
Et si vous n’avez pas trop d’argent à gaspiller, c’est un peu stupide de payer trop cher (expression publicitaire finlandaise, sans offense )
Oui exactement, en ce qui concerne la mémoire libre. Cependant, « la mémoire disponible est en fait une mauvaise chose »… c’est vraiment ce à quoi je faisais référence.
)