J’ai quelques questions concernant cette option. Il est clair que cette option est commentée par défaut dans app.yml et peut améliorer les performances de tri, mais augmente l’utilisation de la mémoire par connexion, mais qu’est-ce que cela signifie réellement ? Cela dépend-il du nombre de connexions ? Qu’est-ce que db_work_mem ? Est-il également défini automatiquement lors de l’installation de Discourse, tout comme db_shared_buffers et UNICORN_WORKERS ? Est-ce une mesure de sécurité à activer ou une option avancée ?
Actuellement, cela ressemble à ceci : #db_work_mem: "40MB"
Le serveur est : Vultr High Frequency Compute 2 vCore, 4096 MB
C’est une question complexe. Vous pouvez consulter la documentation de PostgreSQL pour plus de détails. Plusieurs sujets y abordent le réglage des performances.
Les paramètres par défaut fonctionnent raisonnablement bien.
Si vous rencontrez un problème, vous pouvez le décrire, en précisant le volume de trafic que vous gérez et la taille de votre base de données.
Merci Jay ! En fait, je m’y intéresse simplement. Je cherche des moyens d’améliorer les performances du forum, mais si cela peut causer des problèmes, il vaut peut-être mieux que je le laisse commenté.
Donc, si je l’active, il y a de fortes chances de manquer de mémoire si le réglage n’est pas correct ou si le trafic augmente ? C’est bien cela que j’ai compris.
work_mem ( integer )
Définit la quantité de mémoire de base maximale utilisée par une opération de requête (tel qu’un tri ou une table de hachage) avant d’écrire dans des fichiers temporaires sur le disque. Si cette valeur est spécifiée sans unité, elle est considérée en kilo-octets. La valeur par défaut est de quatre mégaoctets ( 4MB ). Notez que pour une requête complexe, plusieurs opérations de tri ou de hachage peuvent s’exécuter en parallèle ; chaque opération aura généralement le droit d’utiliser autant de mémoire que cette valeur le spécifie avant de commencer à écrire des données dans des fichiers temporaires. De plus, plusieurs sessions en cours d’exécution peuvent effectuer de telles opérations simultanément. Par conséquent, la mémoire totale utilisée peut être plusieurs fois supérieure à la valeur de work_mem ; il est nécessaire de garder cela à l’esprit lors du choix de la valeur. Les opérations de tri sont utilisées pour ORDER BY, DISTINCT et les jointures par fusion. Les tables de hachage sont utilisées dans les jointures par hachage, l’agrégation basée sur le hachage et le traitement basé sur le hachage des sous-requêtes IN.
Les opérations basées sur le hachage sont généralement plus sensibles à la disponibilité de la mémoire que les opérations équivalentes basées sur le tri. La mémoire disponible pour les tables de hachage est calculée en multipliant work_mem par hash_mem_multiplier. Cela permet aux opérations basées sur le hachage d’utiliser une quantité de mémoire qui dépasse le montant de base habituel de work_mem.
Il arrive parfois que cela aide de doubler la mémoire de travail par rapport à la valeur par défaut commentée. Je pense que cela peut être utile sur un gros site où les index sont volumineux, mais je ne suis pas certain. J’ai déjà cassé un site en poussant ce paramètre trop haut.
Si vous souhaitez expérimenter le réglage, vous pouvez consulter le plugin Prometheus et créer de jolis graphiques avec Grafana.
J’ai trouvé la formule ici pour calculer le db_work_mem.
Par défaut, il est configuré pour 100 connexions.
RAM totale * 0,25 / max_connections
J’ai 4096 Mo * 0,25 / 100 = ~10 Mo.
Dans le modèle postgres.template.yml, la valeur par défaut est db_work_mem: "10 Mo", ce qui correspond à ce calcul, je pense. Je pense que ces 10 Mo sont la limite actuelle. Merci Jay
