Bonjour à tous, je travaille sur ce sujet avec @Abdelrahman_MoHamed. Nous avons récemment migré un site comptant environ 500 000 sujets et 3,5 millions d’utilisateurs vers Discourse. Nous sommes auto-hébergés sur GCP. Au cours de ce processus, notre partenaire qui nous a aidés pour la migration a mentionné qu’il pourrait être judicieux d’optimiser Postgres pour obtenir de bonnes performances de la base de données. Notre hypothèse était que la base de données serait optimisée pour Discourse dès sa sortie de la boîte (peut-être l’est-elle ?). Cependant, compte tenu de leur suggestion (celle du partenaire), nous voulions faire un suivi ici.
En bref, s’agit-il de moyens courants d’optimiser Postgres pour une base de données avec les chiffres indiqués ici ?
Merci d’avance pour votre aide !
Avez-vous des preuves plus détaillées que la base de données est le facteur limitant, ou est-ce la cause de ces charges CPU ? Par exemple, la sortie de ps ou top.
Si c’est la base de données, j’imagine qu’il existe un moyen de lui demander sur quelles requêtes elle travaille.
De tels détails pourraient être utiles.
Merci @Ed_S, nous ajouterons bientôt plus de données ici. Pour l’instant, nous surveillons la situation. J’apprécie votre réponse.
cela semble être une combinaison étrange… 22 Go de mémoire mais seulement 4 vCPU ? Surdimensionné en mémoire, mais potentiellement trop peu de cœurs.
Normalement, vous auriez un serveur avec beaucoup plus de vCPU par Go.
C’est parce que le service Web est très parallèle et pour chaque licorne, vous n’avez besoin que d’environ 1 Go.
Chaque licorne peut fonctionner sur un cœur différent, je crois.
C’est peut-être pour cela que vous atteignez si facilement 100 % d’utilisation du CPU.
Je vous recommande d’envisager de passer à une configuration 16/16 ou même 8/8 et de voir si les choses s’améliorent.
Le petit pas de côté est-il autorisé ? Les unicorns sont-ils similaires aux workers de PHP ? Certains documents ont tenté d’expliquer que les unicorns sont en fait des serveurs HTTP avec leurs propres workers qui livrent les requêtes à Ruby, et que c’est pourquoi c’est totalement différent. Mais les deux gèrent les requêtes HTTP, permettant plus de requêtes concurrentes et donc plus de workers PHP, et plus d’unicorns nécessitent plus de RAM — et pour moi, ces deux choses sont pratiquement identiques.
Vrai ou horriblement faux ? J’aimerais comprendre le principe maintenant, car je sais pourquoi, quand et comment ajuster les workers PHP, mais les unicorns sont juste des créatures mystiques et magiques pour moi.
oui, je pense que c’est une comparaison juste
Connexe : Comment un administrateur peut-il savoir s’il a trop peu ou trop de licornes pour son trafic web ?
Connexe : Comment un administrateur peut-il savoir s’il a beaucoup plus de RAM que nécessaire ?
Je crois comprendre que le nombre de licornes est généralement mis à l’échelle en fonction du nombre de CPU, mais ce n’est pas obligatoire - si, par exemple, la configuration de l’hôte a changé depuis l’installation.
La quantité de RAM devrait être mise à l’échelle en fonction de la quantité nécessaire. Je ne sais pas si une importation massive de nombreux articles et utilisateurs signifie nécessairement qu’une plus grande quantité de RAM est nécessaire - la question serait de savoir quelle partie de la base de données est consultée pour chaque requête web, ou chaque tâche régulière ?
Pour moi, une rafale de 10 minutes d’utilisation maximale du CPU, sur fond de très faible utilisation, n’indiquerait pas un problème. (Ce serait un problème si cela signifiait qu’un forum très fréquenté et critique en termes de temps, comme un forum de sport/paris, avait un certain délai pour servir des pages aux heures de pointe d’intérêt. Mais mon forum n’est pas critique en termes de temps ou de performance.)
Je ne sais pas comment on pourrait établir un tableau de la gamme des temps de réponse récents, mais cela pourrait être une bonne donnée à examiner. Soit du côté du serveur web, soit du côté de la base de données.
