Utilisation des ressources / Mémoire

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	2
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

huge_page_size

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Taille d’une page volumineuse qui doit être demandée.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	huge_page_size

logical_decoding_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour le décodage logique.
Type de données	entier
Valeur par défaut	65536
Valeurs autorisées	65536
Type de paramètre	en lecture seule
Documentation	logical_decoding_work_mem

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

min_dynamic_shared_memory

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Quantité de mémoire partagée dynamique réservée au démarrage.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	min_dynamic_shared_memory

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

vacuum_buffer_usage_limit

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la taille du pool de mémoires tampons pour VACUUM, ANALYZE et autovacuum.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	0-16777216
Type de paramètre	dynamique
Documentation	vacuum_buffer_usage_limit

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	2
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

huge_page_size

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Taille d’une page volumineuse qui doit être demandée.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	huge_page_size

logical_decoding_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour le décodage logique.
Type de données	entier
Valeur par défaut	65536
Valeurs autorisées	64-2147483647
Type de paramètre	dynamique
Documentation	logical_decoding_work_mem

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

min_dynamic_shared_memory

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Quantité de mémoire partagée dynamique réservée au démarrage.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	min_dynamic_shared_memory

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

vacuum_buffer_usage_limit

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la taille du pool de mémoires tampons pour VACUUM, ANALYZE et autovacuum.
Type de données	entier
Valeur par défaut	256
Valeurs autorisées	0-16777216
Type de paramètre	dynamique
Documentation	vacuum_buffer_usage_limit

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	2
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

huge_page_size

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Taille d’une page volumineuse qui doit être demandée.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	huge_page_size

logical_decoding_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour le décodage logique.
Type de données	entier
Valeur par défaut	65536
Valeurs autorisées	64-2147483647
Type de paramètre	dynamique
Documentation	logical_decoding_work_mem

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

min_dynamic_shared_memory

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Quantité de mémoire partagée dynamique réservée au démarrage.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	min_dynamic_shared_memory

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	1
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

huge_page_size

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Taille d’une page volumineuse qui doit être demandée.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	huge_page_size

logical_decoding_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour le décodage logique.
Type de données	entier
Valeur par défaut	65536
Valeurs autorisées	64-2147483647
Type de paramètre	dynamique
Documentation	logical_decoding_work_mem

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

min_dynamic_shared_memory

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Quantité de mémoire partagée dynamique réservée au démarrage.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0
Type de paramètre	en lecture seule
Documentation	min_dynamic_shared_memory

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	1
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

logical_decoding_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour le décodage logique.
Type de données	entier
Valeur par défaut	65536
Valeurs autorisées	64-2147483647
Type de paramètre	dynamique
Documentation	logical_decoding_work_mem

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

hash_mem_multiplier

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Multiple de work_mem à utiliser pour les tables de hachage.
Type de données	numeric
Valeur par défaut	1
Valeurs autorisées	1-1000
Type de paramètre	dynamique
Documentation	hash_mem_multiplier

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée utilisée pour la région de mémoire partagée principale.
Type de données	énumération
Valeur par défaut	mmap
Valeurs autorisées	mmap
Type de paramètre	en lecture seule
Documentation	shared_memory_type

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.

autovacuum_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser par chaque processus Worker de nettoyage automatique.
Type de données	entier
Valeur par défaut	-1
Valeurs autorisées	-1-2097151
Type de paramètre	dynamique
Documentation	autovacuum_work_mem

dynamic_shared_memory_type

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Sélectionne l’implémentation de mémoire partagée dynamique utilisée.
Type de données	énumération
Valeur par défaut	posix
Valeurs autorisées	posix
Type de paramètre	en lecture seule
Documentation	dynamic_shared_memory_type

huge_pages

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Active/désactive l’utilisation des pages de mémoire volumineuses. Ce paramètre n’est pas applicable aux serveurs ayant moins de 4 cœurs virtuels.
Type de données	énumération
Valeur par défaut	try
Valeurs autorisées	on,off,try
Type de paramètre	static
Documentation	huge_pages

Description

Les pages volumineuses sont une fonctionnalité qui permet de gérer la mémoire dans des blocs plus volumineux. Vous pouvez généralement gérer des blocs allant jusqu’à 2 Mo, par opposition aux pages standard de 4 Ko.

L’utilisation de pages volumineuses peut offrir des avantages en matière de performances qui déchargent efficacement le processeur :

• Elles réduisent la surcharge associée aux tâches de gestion de la mémoire, comme moins de mémoire tampon de recherche de traduction (TLB) manquent.
• Elles réduisent le temps nécessaire à la gestion de la mémoire.

Plus précisément, dans PostgreSQL, vous pouvez utiliser des pages volumineuses uniquement pour la zone de mémoire partagée. Une partie importante de la zone de mémoire partagée est allouée pour les mémoires tampons partagées.

Un autre avantage est que les pages de grande taille empêchent le transfert de la zone de mémoire partagée sur le disque, ce qui stabilise davantage les performances.

Recommandations

• Pour les serveurs qui ont des ressources de mémoire significatives, évitez de désactiver les pages volumineuses. La désactivation des pages volumineuses peut compromettre les performances.
• Si vous commencez par un serveur plus petit qui ne prend pas en charge les pages volumineuses, mais que vous prévoyez un scale-up vers un serveur qui le fait, conservez le paramètre huge_pages sur TRY pour une transition transparente et des performances optimales.

Notes spécifiques à Azure

Pour les serveurs avec quatre vCores ou plus, d'énormes pages sont automatiquement allouées à partir du système d'exploitation sous-jacent. La fonctionnalité n’est pas disponible pour les serveurs ayant moins de quatre vCores. Le nombre de pages volumineuses est automatiquement ajusté si des paramètres de mémoire partagée sont modifiés, y compris les modifications apportées à shared_buffers.

maintenance_work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la mémoire maximale à utiliser pour les opérations de maintenance comme VACUUM ou Create Index.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	1024-2097151
Type de paramètre	dynamique
Documentation	maintenance_work_mem

Description

maintenance_work_mem est un paramètre de configuration dans PostgreSQL. Il régit la quantité de mémoire allouée pour les opérations de maintenance, telles que VACUUM, CREATE INDEX et ALTER TABLE. Contrairement à work_mem, qui affecte l’allocation de mémoire pour les opérations de requête, maintenance_work_mem est réservé aux tâches qui gèrent et optimisent la structure de la base de données.

Points clés

• Limite de mémoire vide : si vous souhaitez accélérer le nettoyage des tuples morts en augmentant maintenance_work_mem, sachez que VACUUM a une limitation intégrée pour collecter des identificateurs de tuples morts. Il ne peut utiliser que 1 Go de mémoire pour ce processus.
• Séparation de la mémoire pour le nettoyage automatique : le paramètre autovacuum_work_mem vous permet de contrôler la mémoire utilisée par les opérations de nettoyage automatique indépendamment. Ce paramètre agit comme un sous-ensemble de maintenance_work_mem. Vous pouvez décider de la quantité de mémoire utilisée par le nettoyage automatique sans affecter l’allocation de mémoire pour d’autres tâches de maintenance et opérations de définition de données.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur maintenance_work_mem est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur maintenance_work_mem de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre maintenance_work_mem en fonction des valeurs dans la formule suivante.

La formule utilisée pour calculer la valeur de maintenance_work_mem est (long)(82.5 * ln(memoryGiB) + 40) * 1024.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	maintenance_work_mem
2 Gio	99328 Kio
4 Gio	157696 Kio
8 Gio	216064 Kio
16 Gio	274432 Kio
32 Gio	332800 Kio
48 Gio	367616 Kio
64 Gio	392192 Kio
80 Gio	410624 Kio
128 Go	450560 Kio
160 Gio	468992 Kio
192 Gio	484352 Kio
256 Gio	508928 Kio
384 Gio	542720 Kio
432 Gio	552960 Kio
672 Gio	590848 Kio

max_prepared_transactions

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de transactions préparées simultanément. Lors de l’exécution d’un serveur réplica, vous devez définir ce paramètre sur la même valeur que celle du serveur primaire.
Type de données	entier
Valeur par défaut	0
Valeurs autorisées	0-262143
Type de paramètre	static
Documentation	max_prepared_transactions

max_stack_depth

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la profondeur maximale de la pile, en kilo-octets.
Type de données	entier
Valeur par défaut	2048
Valeurs autorisées	2048
Type de paramètre	en lecture seule
Documentation	max_stack_depth

shared_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre de mémoires tampons de mémoire partagée utilisées par le serveur. L'unité est de 8 Ko. Les valeurs autorisées se trouvent dans une plage de 10 % à 75 % de la mémoire disponible.
Type de données	entier
Valeur par défaut	Dépend des ressources (cœurs virtuels, RAM ou espace disque) allouées au serveur.
Valeurs autorisées	16-1073741823
Type de paramètre	static
Documentation	shared_buffers

Description

Le paramètre de configuration shared_buffers détermine la quantité de mémoire système allouée à la base de données PostgreSQL pour la mise en mémoire tampon des données. Il sert de réserve de mémoire centralisée accessible à tous les processus de la base de données.

Lorsque des données sont nécessaires, le processus de base de données vérifie d'abord la mémoire tampon partagée. Si les données requises sont présentes, elles sont rapidement récupérées et contournent une lecture de disque plus longue. Les tampons partagés servent d’intermédiaire entre les processus de base de données et le disque, et réduisent efficacement le nombre d’opérations d’E/S requises.

Notes spécifiques à Azure

La valeur par défaut du paramètre de serveur shared_buffers est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit dans le calcul qui prend en charge le serveur flexible n’a aucun effet sur la valeur par défaut du paramètre de serveur shared_buffers de cette instance.

Chaque fois que vous modifiez le produit attribué à une instance, vous devez également ajuster la valeur du paramètre shared_buffers en fonction des valeurs dans les formules suivantes.

Pour les machines virtuelles ayant jusqu’à 2 Gio de mémoire, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 16384.

Pour les machines virtuelles ayant plus de 2 Gio, la formule utilisée pour calculer la valeur de shared_buffers est memoryGib * 32768.

Compte tenu de la formule précédente, le tableau suivant liste les valeurs affectées à ce paramètre de serveur en fonction de la quantité de mémoire approvisionnée :

Taille de la mémoire	shared_buffers
2 Gio	32 768
4 Gio	131 072
8 Gio	262144
16 Gio	524288
32 Gio	1048576
48 Gio	1572864
64 Gio	2097152
80 Gio	2621440
128 Go	4194304
160 Gio	5242880
192 Gio	6291456
256 Gio	8388608
384 Gio	12582912
432 Gio	14155776
672 Gio	22020096

temp_buffers

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit le nombre maximal de mémoires tampons temporaires utilisés par chaque session de base de données.
Type de données	entier
Valeur par défaut	1024
Valeurs autorisées	100-1073741823
Type de paramètre	dynamique
Documentation	temp_buffers

work_mem

Attribut	Valeur
Catégorie	Utilisation des ressources / Mémoire
Description	Définit la quantité de mémoire à utiliser par les opérations de tri internes et les tables de hachage avant d’écrire dans des fichiers de disque temporaires.
Type de données	entier
Valeur par défaut	4096
Valeurs autorisées	4096-2097151
Type de paramètre	dynamique
Documentation	work_mem

Description

Le paramètre work_mem dans PostgreSQL contrôle la quantité de mémoire allouée pour certaines opérations internes dans la zone de mémoire privée de chaque session de base de données. Par exemple, ces opérations sont le tri et le hachage.

Contrairement aux mémoires tampons partagées, qui se trouvent dans la zone de mémoire partagée, work_mem est alloué dans un espace mémoire privé par session ou par requête. En définissant une taille work_mem adéquate, vous pouvez améliorer considérablement l’efficacité de ces opérations et réduire la nécessité d’écrire des données temporaires sur disque.

Points clés

• Mémoire de connexion privée : work_mem fait partie de la mémoire privée utilisée par chaque session de base de données. Cette mémoire est distincte de la zone de mémoire partagée que shared_buffers utilise.
• Utilisation spécifique aux requêtes : toutes les sessions ou requêtes n’utilisent pas work_mem. Les requêtes simples comme SELECT 1 ne sont pas susceptibles de nécessiter work_mem. Toutefois, des requêtes complexes impliquant des opérations telles que le tri ou le hachage peuvent consommer un ou plusieurs blocs de work_mem.
• Opérations parallèles : pour les requêtes qui s’étendent sur plusieurs back-ends parallèles, chaque back-end peut potentiellement utiliser un ou plusieurs blocs de work_mem.

Supervision et ajustement de work_mem

Il est essentiel de superviser en permanence les performances de votre système et d’ajuster work_mem si nécessaire, principalement si les délais d’exécution des requêtes liées au tri ou aux opérations de hachage sont lents. Voici des façons de superviser les performances à l’aide d’outils disponibles dans le Portail Azure :

• Analyse des performances des requêtes : vérifiez l’onglet Principales requêtes par fichiers temporaires pour identifier les requêtes qui génèrent des fichiers temporaires. Cette situation suggère une nécessité potentielle d’augmenter work_mem.
• Guides de résolution des problèmes : utilisez l’onglet Fichiers temporaires élevés dans les guides de résolution des problèmes pour identifier les requêtes problématiques.

Ajustement granulaire

Lors de la gestion du paramètre work_mem, il est souvent plus efficace d’adopter une approche d’ajustement granulaire plutôt que de définir une valeur globale. Cette approche garantit que vous allouez de manière judicieuse la mémoire en fonction des besoins spécifiques des processus et des utilisateurs. Elle réduit également le risque de rencontrer des problèmes de mémoire insuffisante. Voici comment procéder :

• Niveau utilisateur : si un utilisateur spécifique est principalement impliqué dans des tâches d’agrégation ou de création de rapports, qui sont gourmandes en mémoire, envisagez de personnaliser la valeur work_mem de cet utilisateur. Utilisez la commande ALTER ROLE pour améliorer les performances des opérations de l’utilisateur.

• Niveau de fonction ou de procédure : si des fonctions ou procédures spécifiques génèrent des fichiers temporaires importants, l’augmentation de la valeur work_mem au niveau d’une fonction ou d’une procédure spécifique peut être bénéfique. Utilisez la commande ALTER FUNCTION ou ALTER PROCEDURE pour allouer plus de mémoire à ces opérations.

• Niveau de la base de données : modifiez work_mem au niveau de la base de données si seules des bases de données spécifiques génèrent un nombre élevé de fichiers temporaires.

• Niveau global : si une analyse de votre système révèle que la plupart des requêtes génèrent de petits fichiers temporaires, tandis que seules quelques-unes créent des fichiers volumineux, il peut être prudent d’augmenter globalement la valeur work_mem. Cette action facilite la plupart des requêtes à traiter en mémoire, ce qui vous permet d’éviter les opérations sur disque et d’améliorer l’efficacité. Toutefois, soyez toujours prudent et supervisez l’utilisation de la mémoire sur votre serveur pour vous assurer qu’elle peut gérer l’augmentation de la valeur work_mem.

Détermination de la valeur work_mem minimale pour les opérations de tri

Pour rechercher la valeur minimale de work_mem pour une requête spécifique, en particulier celle qui génère des fichiers de disque temporaires pendant le processus de tri, commencez par prendre en compte la taille de fichier temporaire générée pendant l’exécution de la requête. Par exemple, si une requête génère un fichier temporaire de 20 Mo :

1. Connectez-vous à votre base de données en utilisant psql ou votre client PostgreSQL préféré.
2. Définissez une valeur work_mem initiale légèrement supérieure à 20 Mo pour tenir compte des en-têtes supplémentaires lors du traitement en mémoire. Utilisez une commande telle que : SET work_mem TO '25MB'.
3. Exécutez EXPLAIN ANALYZE sur la requête problématique sur la même session.
4. Passez en revue la sortie pour "Sort Method: quicksort Memory: xkB". Si elle indique "external merge Disk: xkB", augmentez la valeur work_mem de manière incrémentielle et retestez jusqu’à ce que "quicksort Memory" apparaisse. L’apparence de "quicksort Memory" signale que la requête fonctionne désormais en mémoire.
5. Après avoir déterminé la valeur par le biais de cette méthode, vous pouvez l’appliquer globalement ou à des niveaux plus granulaires (comme décrits précédemment) pour répondre à vos besoins opérationnels.