Documentation PostgreSQL 14.22 » Administration du serveur » Configuration du serveur » Consommation des ressources

Précédent | Niveau supérieur | Suivant
20.3. Connexions et authentification | Sommaire | 20.5. Write Ahead Log

## 20.4. Consommation des ressources

### 20.4.1. Mémoire

`shared_buffers` (`integer`)

  Initialise la quantité de mémoire que le serveur de bases de données utilise comme mémoire partagée. La valeur par défaut, en général 128 Mo, peut être automatiquement abaissée si la configuration du noyau ne la supporte pas (déterminé lors de l'exécution de l'initdb). Ce paramètre doit être au minimum de 128 ko + 16 ko par max_connections. Des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. Si cette valeur est spécifiée sans unité, elle sera interprétée comme un nombre de blocs, autrement dit `BLCKSZ` octets, typiquement 8 Ko. (Une valeur personnalisée de `BLCKSZ` changera la valeur minimale.) Ce paramètre ne peut être configuré qu'au lancement du serveur.

  Si vous disposez d'un serveur dédié à la base de données, avec 1 Go de mémoire ou plus, une valeur de départ raisonnable pour ce paramètre est de 25% la mémoire de votre système. Certains cas peuvent nécessiter une valeur encore plus importante pour le `shared_buffers` mais comme PostgreSQL profite aussi du cache du système d'exploitation, il est peu probable qu'une allocation de plus de 40% de la mémoire fonctionnera mieux qu'une valeur plus restreinte. Des valeurs importantes pour le paramètre `shared_buffers` requièrent généralement une augmentation proportionnelle du `max_wal_size`, pour étendre dans le temps les écritures de grandes quantités de données, nouvelles ou modifiées.

  Sur des systèmes comprenant moins d'1 Go de mémoire, un pourcentage plus restreint est approprié pour laisser une place suffisante au système d'exploitation.

`huge_pages` (`enum`)

  Contrôle si les huge pages sont obligatoires pour la principale zone de mémoire partagée. Les valeurs valides sont `try` (le défaut), `on` et `off`. Ce paramètre est seulement configurable au démarrage du serveur. Avec `huge_pages` à `try`, le serveur tentera de demander des huge pages mais se rabattra sur le défaut en cas d'échec. Avec `on`, cet échec empêchera le serveur de démarrer. Avec `off`, il n'y aura pas de demande de huge pages.

  Pour le moment, ce paramètre n'est supporté que sur Linux et Windows. Il est ignoré sur les autres systèmes quand il est à `try`. Sur Linux, il est seulement supporté quand `shared_memory_type` est configuré à `mmap` (la valeur par défaut).

  L'utilisation des huge pages réduit la taille des tables de pages et la consommation CPU pour gérer la mémoire, améliorant ainsi les performances. Pour plus de détails sur la gestion des huge pages sur Linux, voir Section 19.4.5.

  Sous Windows, les huge pages sont connues sous le nom de large pages. Pour les utiliser, vous devez assigner le droit « Verrouiller les pages en mémoire » (Lock Pages in Memory) à l'utilisateur Windows qui fait tourner PostgreSQL. Vous pouvez utiliser l'Éditeur de stratégie de groupe locale (gpedit.msc) pour assigner ce droit à l'utilisateur. Pour démarrer le serveur en ligne de commande en tant que processus autonome, et pas en tant que service Windows, l'invite de commande doit tourner en tant qu'administrateur, ou bien le contrôle de compte d'utilisateur (UAC, User Access Control) doit être désactivé. Quand l'UAC est activé, l'invite de commande normale révoque le droit « Verrouiller les pages en mémoire » de l'utilisateur au démarrage.

  Notez que ce paramètre n'affecte que la partie principale de la mémoire partagée. Des systèmes d'exploitation comme Linux, FreeBSD et Illumos peuvent aussi utiliser les huge pages automatiquement pour les allocations mémoire normales sans demande explicite de PostgreSQL. Sur Linux, cela s'appelle « transparent huge pages » (THP). Elles sont connues pour causer une dégradation des performances avec PostgreSQL pour certains utilisateurs sur certaines versions de Linux ; leur usage est donc actuellement déconseillé (au contraire de l'utilisation explicite de `huge_pages`).

`huge_page_size` (`integer`)

  Contrôle la taille des huge pages, quand elles sont activées avec huge_pages. La valeur par défaut est zéro (`0`). Si initialisé à `0`, la valeur par défaut du système pour la taille des huge pages est utilisée.

  Certaines valeurs communes de la taille des pages sur les serveurs à architecture 64 bits sont : `2MB` et `1GB` (Intel et AMD), `16MB` et `16GB` (IBM POWER), et `64kB`, `2MB`, `32MB` et `1GB` (ARM). Pour plus d'informations, voir Section 19.4.5.

  L'utilisation de valeurs différentes des valeurs par défaut n'est actuellement supportée que sous Linux.

`temp_buffers` (`integer`)

  Configure la quantité maximale de mémoire utilisée pour le cache des objets temporaires à l'intérieur de chaque session à la base. Ce sont des caches locaux à la session utilisés uniquement pour l'accès aux tables temporaires. Si cette valeur est spécifiée sans unité, elle est interprétée comme un nombre de blocs, de `BLCKSZ` octets, typiquement 8 Ko. La valeur par défaut est de 8 Mo (`8MB`). (Si `BLCKSZ` ne vaut pas 8 Ko, la valeur changera de façon proportionnée.) Ce paramètre peut être modifié à l'intérieur de sessions individuelles mais seulement jusqu'à la première utilisation des tables temporaires dans une session ; les tentatives suivantes de changement de cette valeur n'ont aucun effet sur cette session.

  Une session alloue des tampons temporaires en fonction des besoins jusqu'à atteindre la limite donnée par `temp_buffers`. Positionner une valeur importante pour les sessions qui ne le nécessitent pas ne coûte qu'un descripteur de tampon, soit environ 64 octets, par incrément de `temp_buffers`. Néanmoins, si un tampon est réellement utilisé, 8192 autres octets sont consommés pour celui-ci (ou, plus généralement, `BLCKSZ` octets).

`max_prepared_transactions` (`integer`)

  Configure le nombre maximum de transactions simultanément dans l'état « préparées » (voir PREPARE TRANSACTION). Zéro, la configuration par défaut, désactive la fonctionnalité des transactions préparées Ce paramètre ne peut être configuré qu'au lancement du serveur.

  Si vous ne prévoyez pas d'utiliser les transactions préparées, ce paramètre devrait être positionné à zéro pour éviter toute création accidentelle de transactions préparées. Au contraire, si vous les utilisez, il peut être intéressant de positionner `max_prepared_transactions` au minimum à au moins max_connections pour que chaque session puisse avoir sa transaction préparée.

  Lors de l'exécution d'un serveur en attente, vous devez configurer ce paramètre à la même valeur ou à une valeur plus importante que sur le serveur primaire. Sinon, des requêtes pourraient ne pas être autorisées sur le serveur en attente.

`work_mem` (`integer`)

  Indique la quantité de mémoire maximale de base à utiliser pour l'exécution d'une requête (tel qu'un tri ou une table de hachage) avant d'écrire dans des fichiers temporaires sur disque. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. La valeur par défaut est de 4 Mo (`4MB`). Une requête complexe peut réaliser plusieurs opérations de tri ou de hachage exécutées en même temps, chaque opération étant autorisée à utiliser autant de mémoire que cette valeur indique avant de commencer à écrire les données dans des fichiers temporaires. De plus, de nombreuses sessions peuvent exécuter de telles opérations simultanément. La mémoire totale utilisée peut, de ce fait, atteindre plusieurs fois la valeur de `work_mem` ; il est nécessaire de garder cela à l'esprit lors du choix de cette valeur. Les opérations de tri sont utilisées pour `ORDER BY`, `DISTINCT` et les jointures de fusion. Les tables de hachage sont utilisées dans les jointures de hachage, les agrégations, les nœuds Memoize et le traitement des sous-requêtes `IN` fondés sur le hachage.

  Les opérations basées sur le hachage sont généralement plus sensibles à la disponibilité de la mémoire que leur équivalent basé sur le tri. La mémoire disponible pour les tables de hachages est calculée en multipliant `work_mem` par `hash_mem_multiplier`. Cela rend possible pour les opérations de hachage d'utiliser une quantité de mémoire qui dépasse la quantité de base proposée par `work_mem`.

`hash_mem_multiplier` (`floating point`)

  Utilisé pour calculer la quantité maximale de mémoire que les opérations basées sur le hachage peuvent utiliser. La limite finale est déterminée en multipliant `work_mem` par `hash_mem_multiplier`. La valeur par défaut est 1.0, ce qui rend les opérations de hachage sujettes au même maximum que`work_mem` pour les opérations basées sur le tri.

  Pensez à augmenter `hash_mem_multiplier` dans les environnements où l'utilisation de fichiers temporaires survient fréquemment, tout spécialement quand augmenter uniquement `work_mem` a pour résultat une pression mémoire trop importante (la pression mémoire prend typiquement la forme d'erreurs pour manque de mémoire). Une configuration de 1.5 ou 2.0 pourrait être efficace avec des charges de travail variées. Des configurations plus hautes (entre 2.0 et 8.0, voire encore plus) pourraient être plus efficaces dans les environnements où `work_mem` a déjà été augmenté à 40 Moi, voire plus.

`maintenance_work_mem` (`integer`)

  Indique la quantité maximale de mémoire que peuvent utiliser les opérations de maintenance telles que `VACUUM`, `CREATE INDEX` et `ALTER TABLE ADD FOREIGN KEY`. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. La valeur par défaut est de 64 Mo. Puisque seule une de ces opérations peut être exécutée à la fois dans une session et que, dans le cadre d'un fonctionnement normal, peu d'opérations de ce genre sont exécutées concurrentiellement sur une même installation, il est possible d'initialiser cette variable à une valeur bien plus importante que `work_mem`. Une grande valeur peut améliorer les performances des opérations VACUUM et de la restauration des sauvegardes.

  Quand autovacuum fonctionne, un maximum de autovacuum_max_workers fois cette quantité de mémoire peut être utilisée. Il convient donc de s'assurer de ne pas configurer la valeur par défaut de façon trop importante. Il pourrait être utile de contrôler ceci en configurant autovacuum_work_mem séparément.

  Notez que pour la récupération des identifiants de lignes mortes, `VACUUM` est capable d'utiliser uniquement 1 Go de mémoire.

`autovacuum_work_mem` (`integer`)

  Indique la quantité maximale de mémoire à utiliser pour chaque processus autovacuum worker. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. Ce paramètre vaut -1 par défaut, indiquant que la valeur de maintenance_work_mem doit être utilisée à la place. Ce paramétrage n'a pas d'effet sur le comportement de `VACUUM` lorsqu'il est exécuté dans d'autres contextes. Ce paramètre peut seulement être configuré dans le fichier `postgresql.conf` ou sur la ligne de commande du serveur.

  Pour la récupération des identifiants de lignes mortes, autovacuum est capable d'utiliser au maximum `1 Go` de mémoire, donc configurer `autovacuum_work_mem` à une valeur supérieure n'a aucun effet sur le nombre de lignes mortes que l'autovacuum peut récupérer lors du parcours d'une table.

`logical_decoding_work_mem` (`integer`)

  Indique la quantité de mémoire à utiliser pour le décodage logique, avant que certaines données décodées ne soient écrites sur les disques locaux. Ceci limite la quantité de mémoire utilisée par la réplication logique en flux. Elle vaut par défaut 64 Mo (`64MB`). Comme chaque connexion de réplication utilise un seul tampon de cette taille et qu'une installation ne peut avoir normalement beaucoup de connexions simultanées de ce type (étant donné qu'elles sont limitées par `max_wal_senders`), il est plus sûr de configurer cette valeur bien plus haute que `work_mem`, réduisant la quantité de données décodées écrites sur disque.

`max_stack_depth` (`integer`)

  Indique la profondeur maximale de la pile d'exécution du serveur. La configuration idéale pour ce paramètre est la limite réelle de la pile assurée par le noyau (configurée par `ulimit -s` ou équivalent local) à laquelle est soustraite une marge de sécurité d'un Mo environ. La marge de sécurité est nécessaire parce que la profondeur de la pile n'est pas vérifiée dans chaque routine du serveur mais uniquement dans les routines clés potentiellement récursives. Si cette valeur est indiquée sans unité, elle est considérée être en Ko. Le paramétrage par défaut est de 2 Mo, valeur faible qui implique peu de risques. Néanmoins, elle peut s'avérer trop petite pour autoriser l'exécution de fonctions complexes. Seuls les super-utilisateurs peuvent modifier ce paramètre.

  Configurer ce paramètre à une valeur plus importante que la limite réelle du noyau signifie qu'une fonction récursive peut occasionner un arrêt brutal d'un processus serveur particulier. Sur les plateformes où PostgreSQL peut déterminer la limite du noyau, il interdit de positionner cette variable à une valeur inadéquate. Néanmoins, toutes les plateformes ne fournissent pas cette information, et une grande attention doit être portée au choix de cette valeur.

`shared_memory_type` (`enum`)

  Indique l'implémentation de mémoire partagée que le serveur doit utiliser pour la principale région de mémoire partagée contenant le cache disque de PostgreSQL et d'autres données partagées. Les valeurs possibles sont `mmap` (pour la mémoire partagée anonyme allouée en utilisant `mmap`), `sysv` (pour la mémoire partagée System V allouée via `shmget`) et `windows` (pour la mémoire partagée Windows). Toutes les valeurs ne sont pas forcément supportées sur toutes les plateformes ; la première option supportée est la valeur par défaut pour cette plateforme. L'utilisation de l'option `sysv`, qui n'est pas la valeur par défaut quelque soit la plateforme, est généralement non conseillée car elle nécessite habituellement une configuration du noyau différente de la configuration par défaut pour permettre de grosses allocations (voir Section 19.4.1). Ce paramètre est seulement configurable au démarrage du serveur.

`dynamic_shared_memory_type` (`enum`)

  Indique l'implémentation de mémoire partagée dynamique que le serveur doit utiliser. Les valeurs possibles sont `posix` (pour la mémoire partagée POSIX allouée en utilisant `shm_open`), `sysv` (pour la mémoire partagée System V allouée en* utilisant `shmget`), `windows` (pour la mémoire partagée Windows), `mmap` (pour simuler la mémoire partagée en utilisant les fichiers de mémoire enregistrés dans le répertoire des données). Toutes les valeurs ne sont pas forcément supportées sur toutes les plateformes ; la première option supportée est la valeur par défaut pour cette plateforme. L'utilisation de l'option `mmap`, qui n'est la valeur par défaut d'aucune plateforme, est généralement déconseillée car le système d'exploitation pourrait écrire des pages modifiées sur disque de manière répétée, augmentant la charge disque du système. Néanmoins, cela peut se révéler utile pour débugger, quand le répertoire `pg_dynshmem` est stocké dans un disque RAM ou quand les autres options de mémoire partagée ne sont pas disponibles. Ce paramètre est seulement configurable au démarrage du serveur.

`min_dynamic_shared_memory` (`integer`)

  Indique la quantité de mémoire qui doit être allouée au démarrage du serveur pour l'execution en parallèle de requêtes. Quand cette partie de la mémoire est insuffisante pour les requêtes concurrentes, de nouvelles requêtes parallèles essayent d'allouer temporairement plus de mémoire partagée en utilisant la méthode configurée avec `dynamic_shared_memory_type`, ce qui peut être plus lent à cause de la consommation de ressources de la gestion de la mémoire. La mémoire allouée au démarrage avec `min_dynamic_shared_memory` est affectée par le paramètre `huge_pages` au niveau du système d'exploitation lorsque c'est supporté et peut bénéficier de plus grandes pages sur les systèmes d'exploitation où c'est géré automatiquement. La valeur par défaut est `0` (aucune).

### 20.4.2. Disque

`temp_file_limit` (`integer`)

  Spécifie la quantité maximale d'espace disque qu'un processus peut utiliser pour les fichiers temporaires, comme par exemple ceux utilisés pour les tris et hachages, ou le fichier de stockage pour un curseur détenu. Une transaction tentant de dépasser cette limite sera annulée. La valeur a pour unité le ko. La valeur spéciale `-1` (valeur par défaut) signifie sans limite. Seuls les super-utilisateurs peuvent modifier cette configuration.

  Ce paramètre contraint l'espace total utilisé à tout instant par tous les fichiers temporaires utilisés pour un processus PostgreSQL donnée. Il doit être noté que l'espace disque utilisé pour les tables temporaires explicites, à l'opposé des fichiers temporaires utilisés implicitement pour l'exécution des requêtes, n'est pas pris en compte pour cette limite.

### 20.4.3. Usage des ressources du noyau

`max_files_per_process` (`integer`)

  Positionne le nombre maximum de fichiers simultanément ouverts par sous-processus serveur. La valeur par défaut est de 1000 fichiers. Si le noyau assure une limite par processus, il n'est pas nécessaire de s'intéresser à ce paramètre. Toutefois, sur certaines plateformes (notamment les systèmes BSD) le noyau autorise les processus individuels à ouvrir plus de fichiers que le système ne peut effectivement en supporter lorsqu'un grand nombre de processus essayent tous d'ouvrir ce nombre de fichiers. Si le message « Too many open files » (« Trop de fichiers ouverts ») apparaît, il faut essayer de réduire ce paramètre. Ce paramètre ne peut être configuré qu'au lancement du serveur.

### 20.4.4. Report du VACUUM en fonction de son coût

Lors de l'exécution des commandes VACUUM et ANALYZE, le système maintient un compteur interne qui conserve la trace du coût estimé des différentes opérations d'entrée/sortie réalisées. Quand le coût accumulé atteint une limite (indiquée par `vacuum_cost_limit`), le processus traitant l'opération s'arrête un court moment (précisé par `vacuum_cost_delay`). Puis, il réinitialise le compteur et continue l'exécution.

Le but de cette fonctionnalité est d'autoriser les administrateurs à réduire l'impact des entrées/sorties de ces commandes en fonction de l'activité des bases de données. Nombreuses sont les situations pour lesquelles il n'est pas très important que les commandes de maintenance telles que `VACUUM` et `ANALYZE` se finissent rapidement, mais il est généralement très important que ces commandes n'interfèrent pas de façon significative avec la capacité du système à réaliser d'autres opérations sur les bases de données. Le report du VACUUM en fonction de son coût fournit aux administrateurs un moyen d'y parvenir.

Cette fonctionnalité est désactivée par défaut pour les commandes `VACUUM` lancées manuellement. Pour l'activer, la variable `vacuum_cost_delay` doit être initialisée à une valeur différente de zéro.

`vacuum_cost_delay` (`floating point`)

  Indique le temps, en millisecondes, de repos du processus quand la limite de coût a été atteinte. Si cette valeur est indiquée sans unité, elle est comprise comme des millisecondes. La valeur par défaut est zéro, ce qui désactive la fonctionnalité de report du VACUUM en fonction de son coût. Une valeur positive active cette fonctionnalité.

  Lors d'utilisation de vacuum basée sur le coût, les valeurs appropriées pour `vacuum_cost_delay` sont habituellement assez petites, inférieures à 1 milliseconde. Bien que `vacuum_cost_delay` puisse être configuré à des valeurs à virgule flottante en millisecondes, ces délais pourraient ne pas pouvoir être mesurés de façon précise sur les anciennes plateformes. Sur ce type de plateforme, augmenter la consommation de ressource du `VACUUM` au-dessus de ce que vous obtiendrez avec 1ms nécessitera de modifier les autres paramètres de coût. De plus, vous devrez garder `vacuum_cost_delay` aussi petit que ce que votre plateforme peut mesurer correctement. De gros délais n'aident pas.

`vacuum_cost_page_hit` (`integer`)

  Indique Le coût estimé du nettoyage par VACUUM d'un tampon trouvé dans le cache des tampons partagés. Cela représente le coût de verrouillage de la réserve de tampons, la recherche au sein de la table de hachage partagée et le parcours du contenu de la page. La valeur par défaut est 1.

`vacuum_cost_page_miss` (`integer`)

  Indique le coût estimé du nettoyage par VACUUM d'un tampon qui doit être lu sur le disque. Cela représente l'effort à fournir pour verrouiller la réserve de tampons, rechercher dans la table de hachage partagée, lire le bloc désiré sur le disque et parcourir son contenu. La valeur par défaut est 2.

`vacuum_cost_page_dirty` (`integer`)

  Indique le coût estimé de modification par VACUUM d'un bloc précédemment vide (clean block). Cela représente les entrées/sorties supplémentaires nécessaires pour vider à nouveau le bloc modifié (dirty block) sur le disque. La valeur par défaut est 20.

`vacuum_cost_limit` (`integer`)

  Indique Le coût cumulé qui provoque l'endormissement du processus de VACUUM. La valeur par défaut est 200.

### Note

Certaines opérations détiennent des verrous critiques et doivent donc se terminer le plus vite possible. Les reports de VACUUM en fonction du coût ne surviennent pas pendant ces opérations. De ce fait, il est possible que le coût cumulé soit bien plus important que la limite indiquée. Pour éviter des délais inutilement longs dans de tels cas, le délai réel est calculé de la façon suivante : `vacuum_cost_delay` * `accumulated_balance` / `vacuum_cost_limit` avec un maximum de `vacuum_cost_delay` * 4.

### 20.4.5. Processus d'écriture en arrière-plan

Il existe un processus serveur séparé appelé background writer dont le but est d'écrire les tampons « sales » (parce que nouveaux ou modifiés). Quand le nombre de tampons partagés propres semble insuffisant, le background writer écrit quelques tampons sales au système de fichiers et les marque comme étant propres. Ceci réduit la probabilité que les processus serveur gérant les requêtes des utilisateurs ne soient dans l'incapacité de trouver des tampons propres et doivent écrire eux-mêmes des tampons sales. Néanmoins, ce processus d'écriture en tâche de fond implique une augmentation globale de la charge des entrées/sorties disque car, quand une page fréquemment modifiée pourrait n'être écrite qu'une seule fois par CHECKPOINT, le processus d'écriture en tâche de fond pourrait l'avoir écrit plusieurs fois si cette page a été modifiée plusieurs fois dans le même intervalle. Les paramètres discutés dans cette sous-section peuvent être utilisés pour configurer finement son comportement pour les besoins locaux.

`bgwriter_delay` (`integer`)

  Indique le délai entre les tours d'activité du processus d'écriture en arrière-plan. À chaque tour, le processus écrit un certain nombre de tampons modifiés (contrôlable par les paramètres qui suivent). Puis, il s'endort pour `bgwriter_delay` millisecondes et recommence. Quand il n'y a pas de tampons modifiés dans le cache, il s'endort plus profondément sans considération du `bgwriter_delay`. Si cette valeur est indiquée sans unité, elle est prise comme des millisecondes. La valeur par défaut est de 200 millisecondes. Sur de nombreux systèmes, la résolution réelle du `sleep` est de 10 millisecondes ; positionner `bgwriter_delay` à une valeur qui n'est pas un multiple de 10 peut avoir le même résultat que de le positionner au multiple de 10 supérieur. Ce paramètre ne peut être configuré que dans le fichier `postgresql.conf` ou indiqué sur la ligne de commande.

`bgwriter_lru_maxpages` (`integer`)

  Nombre maximum de tampons qui peuvent être écrits à chaque tour par le processus d'écriture en tâche de fond. Le configurer à zéro désactive l'écriture en tâche de fond. (Notez que les checkpoints ne sont pas affectés. Ils sont gérés par un autre processus, dédié à cette tâche.) La valeur par défaut est de 100 tampons. Ce paramètre ne peut être configuré que dans le fichier `postgresql.conf` ou indiqué sur la ligne de commande.

`bgwriter_lru_multiplier` (`floating point`)

  Le nombre de tampons sales écrits à chaque tour est basé sur le nombre de nouveaux tampons qui ont été requis par les processus serveur lors des derniers tours. Le besoin récent moyen est multiplié par `bgwriter_lru_multiplier` pour arriver à une estimation du nombre de tampons nécessaire au prochain tour. Les tampons sales sont écrits pour qu'il y ait ce nombre de tampons propres, réutilisables. (Néanmoins, au maximum `bgwriter_lru_maxpages` tampons sont écrits par tour.) De ce fait, une configuration de 1.0 représente une politique d'écriture « juste à temps » d'exactement le nombre de tampons prédits. Des valeurs plus importantes fournissent une protection contre les pics de demande, alors qu'une valeur plus petite laisse intentionnellement des écritures aux processus serveur. La valeur par défaut est de 2. Ce paramètre ne peut être configuré que dans le fichier `postgresql.conf` ou indiqué sur la ligne de commande.

`bgwriter_flush_after` (`integer`)

  Quand plus de ce nombre d'octets ont été écrit par le processus d'écriture en tâche de fond (bgwriter), tente de forcer le système d'exploitation à écrire les données sur disque. Faire cela limite la quantité de données modifiées dans le cache disque du noyau, réduisant le risque de petites pauses dues à l'exécution d'un `fsync` à la fin d'un checkpoint ou à l'écriture massive en tâche de fond des données modifiées. Souvent, cela réduira fortement la latence des transactions mais il existe aussi quelques cas de dégradation des performances, tout spécialement avec les charges de travail plus importantes que shared_buffers, mais plus petites que le cache disque du système d'exploitation. Ce paramètre pourrait ne pas avoir d'effet sur certaines plateformes. L'intervalle valide se situe entre `0`, qui désactive le « writeback » forcé, et `2MB`. Si cette valeur est indiquée sans unité, elle est compris comme des blocs, autrement dit `BLCKSZ` octets, typiquement 8 Ko. La valeur par défaut est `512KB` sur Linux, `0` ailleurs. (Si `BLCKSZ` ne vaut pas 8 ko, les valeurs par défaut et maximales évoluent de façon proportionnelles à cette constante.) Ce paramètre est seulement configurable dans le fichier `postgresql.conf` et à la ligne de commande.

Des valeurs plus faibles de `bgwriter_lru_maxpages` et `bgwriter_lru_multiplier` réduisent la charge supplémentaire des entrées/sorties induite par le processus d'écriture en arrière-plan. En contrepartie, la probabilité que les processus serveurs effectuent plus d'écritures par eux-mêmes augmente, ce qui retarde les requêtes interactives.

### 20.4.6. Comportement asynchrone

`backend_flush_after` (`integer`)

  Lorsqu'une quantité de données supérieure à cette valeur doit être écrite par un seul processus, une tentative de forcer le système d'exploitation à écrire sur le stockage sous-jacent est faite. En agissant ainsi, on limite la quantité de données modifiée dans le cache du noyau, réduisant ainsi la probabilité d'une perte de temps quand la fonction `fsync` est appelée à la fin du checkpoint ou lorsque le système d'exploitation écrit beaucoup de données en arrière-plan. Souvent, cela permet de réduire grandement la latence des transactions mais il est possible dans certains cas, en particulier pour les volumes de donnés plus importants que shared_buffers mais plus petits qu'un bloc de cache du système d'exploitation, que les performances en soient dégradées. Ce paramètre peut aussi n'avoir aucun effet sur certaines plateformes. Si la valeur est indiquée sans unité, elle est comprise en blocs, c'est-à-dire en `BLCKSZ` octets, généralement 8 ko. Les valeurs doivent être comprises entre `0`, ce qui désactive la fonctionnalité d'écritures forcées et `2Mo`. La valeur par défaut est `0`. (Si `BLCKSZ` n'est pas configuré à 8 ko, la valeur maximale est ajustée proportionnellement.)

`effective_io_concurrency` (`integer`)

  Positionne le nombre d'opérations d'entrées/sorties disque concurrentes que PostgreSQL pense pouvoir exécuter simultanément. Augmenter cette valeur va augmenter le nombre d'opérations d'entrée/sortie que chaque session PostgreSQL individuelle essayera d'exécuter en parallèle. Les valeurs autorisées vont de 1 à 1000, ou zéro pour désactiver l'exécution de requêtes d'entrée/sortie asynchrones. Actuellement, ce paramètre ne concerne que les parcours de type bitmap heap.

  Pour les disques magnétiques, un bon point départ pour ce paramètre est le nombre de disques que comprend un agrégat par bande RAID 0 ou miroir RAID 1 utilisé pour la base de données. (Pour du RAID 5, le disque de parité ne devrait pas être pris en compte.) Toutefois, si la base est souvent occupée par de nombreuses requêtes exécutées dans des sessions concurrentes, des valeurs plus basses peuvent être suffisantes pour maintenir le groupe de disques occupé. Une valeur plus élevée que nécessaire pour maintenir les disques occupés n'aura comme seul résultat que de surcharger le processeur. Les SSD et autres méthodes de stockage basées sur de la mémoire peuvent souvent traiter un grand nombre de demandes concurrentes, donc la meilleure valeur pourrait être dans les centaines.

  Les entrées/sorties asynchrones dépendent de la présence d'une fonction `posix_fadvise` efficace, ce que n'ont pas certains systèmes d'exploitation. Si la fonction n'est pas présente, alors positionner ce paramètre à une valeur autre que zéro entraînera une erreur. Sur certains systèmes (par exemple Solaris), cette fonction est présente mais n'a pas d'effet.

  La valeur par défaut est 1 sur les systèmes supportés, et 0 pour les autres. Cette valeur peut être surchargée pour les tables d'un tablespace particulier en configuration le paramètre tablespace du même nom (voir ALTER TABLESPACE).

`maintenance_io_concurrency` (`integer`)

  Similaire à `effective_io_concurrency`, mais utilisé pour le travail de maintenance réaliser pour les nombreuses sessions clientes.

  La valeur par défaut est 10 sur les systèmes supportés, 0 sinon. Cette valeur peut être surchargée pour les tables d'un tablespace particulier en configurant le paramètre de même nom pour ce tablespace (voir ALTER TABLESPACE).

`max_worker_processes` (`integer`)

  Configure le nombre maximum de background workers acceptés par le système. Ce paramètre n'est configurable qu'au démarrage du serveur. La valeur par défaut est 8.

  S'il s'agit de la configuration d'un serveur secondaire, vous devez configurer ce paramètre à une valeur supérieure ou égale à celui du serveur primaire. Dans le cas contraire, il ne sera pas possible d'exécuter des requêtes sur le serveur secondaire.

`max_parallel_workers_per_gather` (`integer`)

  Configure le nombre maximum de processus parallèles pouvant être lancé par un seul nœud `Gather` ou `Gather Merge`. Les processus parallèles sont pris dans l'ensemble de processus établi par max_worker_processes, limité par max_parallel_workers. Notez que le nombre demandé de processus parallèles pourrait ne pas être disponible à l'exécution. Si cela survient, le plan s'exécutera avec moins de processus qu'attendu, ce qui pourrait être inefficace. La valeur par défaut est 2. Positionner cette valeur à 0 désactive l'exécution parallélisée de requête.

  Notez que les requêtes parallélisées peuvent consommer considérablement plus de ressources que des requêtes non parallélisées parce que chaque processus parallèle est un processus totalement séparé qui a en gros le même impact sur le système qu'une session utilisateur supplémentaire. Ceci doit être pris en considération lors du choix d'une valeur pour ce paramètre, ainsi que lors de la configuration d'autres paramètres qui contrôlent l'utilisation des ressources, comme par exemple work_mem. Les limites de ressources comme `work_mem` sont appliquées individuellement pour chaque processus, ce qui signifie que l'utilisation totale pourrait être bien plus importante que pour un seul processus. Par exemple, une requête parallélisée utilisant quatre processus pourrait utiliser jusqu'à cinq fois plus de CPU, de mémoire, de bande passante disque, et ainsi de suite qu'une requête non parallélisée.

  Pour plus d'informations sur les requêtes parallélisées, voir Chapitre 15.

`max_parallel_maintenance_workers` (`integer`)

  Indique le nombre maximum de workers parallèles qu'une commande utilitaire peut démarrer. Actuellement, les commandes utilitaires qui supportent les workers parallèles est `CREATE INDEX`, et seulement à la création d'un index B-tree, et `VACUUM` sans l'option `FULL`. Les workers parallèles sont déduits du pool de processus défini par max_worker_processes, dans la limite de max_parallel_workers. Notez que le nombre de workers demandé peut ne pas être disponible lors de l'exécution. Si cela arrive, l'opération utilitaire fonctionnera avec moins de workers qu'attendu. Le défaut est de 2. Passer cette valeur à 0 désactive l'utilisation des workers parallèles par les commandes utilitaires.

  Notez que les commandes utilitaires parallélisées ne devraient pas consommer beaucoup plus de mémoire que leur équivalent non parallélisé. Cette stratégie diffère de celle adoptée pour les requêtes parallélisées, où les limites de ressources s'appliquent généralement par processus (worker). Les commandes utilitaires parallélisées traitent la limite de ressource `maintenance_work_mem` comme une limite à appliquer à la commande entière, sans considération du nombre de workers parallèles. Cependant, les commandes utilitaires parallélisées peuvent consommer nettement plus de CPU et de bande passante.

`max_parallel_workers` (`integer`)

  Positionne le nombre maximum de workers que le système peut supporter pour le besoin des requêtes parallèles. La valeur par défaut est 8. Lorsque cette valeur est augmentée ou diminuée, pensez également à modifier max_parallel_maintenance_workers et max_parallel_workers_per_gather. De plus, veuillez noter que positionner cette valeur plus haut que max_worker_processes n'aura pas d'effet puisque les workers parallèles sont pris de la réserve de processus établie par ce paramètre.

`parallel_leader_participation` (`boolean`)

  Permet au processus leader d'exécuter le plan de la requête sur les nœuds `Gather` et `Gather Merge` au lieu d'attendre le processus en cours. Positionner ce paramètre à `off` réduit la probabilité qu'un processus soit bloqué parce que le processus leader ne lit pas les données assez vite mais impose que le processus leader attende que les autres processus aient démarré avant que les premières lignes ne soient produites. Le degré à partir duquel le processus leader peut améliorer ou détériorer les performances dépend du type de plan d'exécution, du nombre de processus parallèles et de la durée d'exécution de la requête.

`old_snapshot_threshold` (`integer`)

  Configure la durée minimale d'utilisation d'une image sans risque d'erreur `snapshot too old` survenant lors de l'utilisation de l'image. Les données mortes depuis plus longtemps que cette limite peuvent être nettoyées. Ceci peut aider à empêcher la fragmentation dans le cas de snapshots qui restent utiliser sur une longue période. Pour empêcher des résultats incorrects suite au nettoyage des données qui auraient été visibles par l'image, une erreur est générée quand l'image est plus ancienne que cette limite et que l'image est utilisée pour lire un bloc qui a été modifié depuis la construction du snapshot.

  Si cette valeur est spécifiée sans unité, elle est considérée comme un nombre de minutes. Une valeur de `-1` (valeur par défaut) désactive cette fonctionnalité, en configurant la limite d'âge à l'infini. Ce paramètre peut seulement être configuré au démarrage du serveur.

  Les valeurs utiles en production vont probablement d'un petit nombre d'heures à quelques jours. De petites valeurs (tels que `0` ou `1min`) sont seulement autorisés parce qu'ils pourraient être utiles pour des tests. Bien qu'une configuration aussi haute que `60d` est autorisée, notez que dans de nombreux cas, une fragmentation extrême ou une réutilisation des identifiants de transaction pourrait survenir très rapidement.

  Quand cette fonctionnalité est activée, l'espace libérée à la fin de la relation ne peut pas être rendu au système d'exploitation car cela supprimerait les informations nécessaires pour détecter la condition « snapshot too old ». Tout l'espace alloué pour une relation reste associé avec cette relation pour une réutilisation par cette relation sauf si elle est explicitement libérée (par exemple, avec `VACUUM FULL`).

  Ce paramètre ne tente pas de garantir qu'une erreur sera générée sous quelques circonstances. En fait, si les résultats corrects peuvent être générés à partir (par exemple) d'un curseur qui a matérialisé un ensemble de résultat, aucune erreur ne sera renvoyée même si les lignes impactées dans la table de référence ont été nettoyées. Certaines tables ne peuvent pas être nettoyées tôt proprement, et donc ne seront pas affectées par ce paramètre, comme les catalogues systèmes. Pour ces tables, ce paramètre ne réduira pas la fragmentation et ne pourra être la raison d'une erreur « snapshot too old » lors de son parcours.