Y a-t-il des guides (ou des sujets ici sur le forum) qui fournissent des conseils pour optimiser un serveur hébergeant des sites Discourse en termes de performances ?
J’ai exécuté ./Discourse-set et cela a alloué un quart de la RAM (à 4096 Mo) et ajouté 8 workers Unicorn. Mais y a-t-il autre chose que nous puissions faire, ou pouvons-nous ajuster ces paramètres ?
Le serveur dispose de 64 Go de RAM ECC et de deux SSD NVMe de 512 Go NVMe (en configuration RAID). En regardant avec top, seulement environ 5 Go de mémoire sont utilisés, avec 57392484 avail Mem. Il exécute également d’autres sites non Docker, mais ils n’utilisent pas beaucoup de ressources, et MySQL est déjà optimisé pour une base de données de 2 Go. Les charges moyennes sont généralement inférieures à 1,0 (généralement autour de 0,50 à 1,0, avec quelques dépassements occasionnels). Aucun problème n’a été signalé, mais j’espère exploiter au maximum les ressources du serveur.
Je me demande s’il faut commencer par doubler db_shared_buffers… et qu’en est-il de #db_work_mem: "40MB" qui est actuellement commenté ?
Toutes les informations et conseils sont les bienvenus
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.
)