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 32 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 personnalisées de BLCKSZ agissent sur ce minimum.) Des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. 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 checkpoint_segments, 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. De plus, sur Windows, les grandes valeurs pour shared_buffers ne sont pas aussi efficaces. Vous pouvez avoir de meilleurs résultats en conservant un paramétrage assez bas et en utilisant le cache du système d'exploitation à la place. L'échelle habituelle pour shared_buffers sur des systèmes Windows va de 64 Mo à 512 Mo.
L'augmentation de ce paramètre peut obliger PostgreSQL™ à réclamer plus de mémoire partagée System V que ce que la configuration par défaut du système d'exploitation ne peut gérer. Voir la Section 17.4.1, « Mémoire partagée et sémaphore » pour de plus amples informations sur l'ajustement de ces paramètres, si nécessaire.
Configure le nombre maximum de tampons temporaires utilisés par chaque session de la base de données. Ce sont des tampons locaux à la session utilisés uniquement pour accéder aux tables temporaires. La valeur par défaut est de 8 Mo. 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).
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.
Augmenter ce paramètre peut conduire PostgreSQL™ à réclamer plus de mémoire partagée System V que ne le permet la configuration par défaut du système d'exploitation. Voir la Section 17.4.1, « Mémoire partagée et sémaphore » pour les informations concernant la façon d'ajuster ces paramètres, si nécessaire.
Indique la quantité de mémoire que les opérations de tri interne et les tables de hachage peuvent utiliser avant de basculer sur des fichiers disque temporaires. La valeur par défaut est de 1 Mo. Pour une requête complexe, il peut y avoir plusieurs opérations de tri ou de hachage exécutées en parallèle ; chacune peut utiliser de la mémoire à hauteur de cette valeur avant de commencer à placer 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 et le traitement des sous-requêtes IN fondés sur le hachage.
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. La valeur par défaut est de 16 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.
Notez que quand autovacuum fonctionne, un maximum de autovacuum_max_workers fois cette quantité de mémoire peut être utilisé, donc faites attention à ne pas configurer la valeur par défaut de façon trop importante.
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 telles que l'évaluation d'une expression. 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 superutilisateurs 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.
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.
Indique les bibliothèques partagées à précharger au démarrage du serveur. S'il faut précharger plusieurs bibliothèques, leurs noms doivent être séparés par des virgules. Par exemple, '$libdir/malib' implique le préchargement de malib.so (ou, sur certaines plateformes, malib.sl) depuis le répertoire d'installation des bibliothèques standard. Ce paramètre ne peut être configuré qu'au lancement du serveur.
Les bibliothèques des langages procéduraux de PostgreSQL™ peuvent être préchargées ainsi, typiquement en utilisant la syntaxe '$libdir/plXXX' où XXX est pgsql, perl, tcl ou python.
Le préchargement d'une bibliothèque partagée permet d'éviter le temps de chargement de la bibliothèque à sa première utilisation. Toutefois, la durée de démarrage de chaque nouveau processus serveur peut augmenter légèrement, même si aucun de ces processus n'utilise la bibliothèque. Ce paramètre n'est réellement recommandé que pour les bibliothèques utilisées dans la plupart des sessions.
![[Note]](images/note.png)
Sur un hôte Windows, le préchargement d'une bibliothèque au lancement du serveur ne réduit pas le temps nécessaire au lancement de chaque nouveau processus serveur ; chaque processus serveur recharge toutes les bibliothèques déjà chargées. Néanmoins, shared_preload_libraries est toujours utile sur les hôtes Windows car certaines bibliothèques partagées peuvent nécessiter des opérations qui ne peuvent avoir lieu qu'au lancement du serveur (par exemple, une bibliothèque partagée peut réserver des verrous légers ou de la mémoire partagée, ce qui ne peut être fait une fois le serveur démarré).
Si une bibliothèque indiquée est introuvable, le démarrage du serveur échoue.
Chaque bibliothèque supportée par PostgreSQL possède un « bloc magique » qui est vérifié pour garantir la compatibilité. Pour cette raison, seules les bibliothèques PostgreSQL peuvent être chargées de cette façon.
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 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.
Indique le temps, en millisecondes, de repos du processus quand la limite de coût a été atteinte. 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é. Sur de nombreux systèmes, la résolution réelle du sleep est de 10 millisecondes ; configurer vacuum_cost_delay à une valeur qui n'est pas un multiple de 10 conduit alors au même résultat que de le configurer au multiple de 10 supérieur.
Lors d'utilisation de vacuum basée sur le coût, les valeurs appropriées pour vacuum_cost_delay sont habituellement assez petites, de l'ordre de 10 à 20 millisecondes. Il est préférable d'ajuster la consommation de ressource de vacuum en changeant les autres paramètres de coût de vacuum.
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.
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 10.
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.
Indique Le coût cumulé qui provoque l'endormissement du processus de VACUUM. La valeur par défaut est 200.
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.
Il existe un processus serveur distinct, nommé processus d'écriture en arrière-plan (background writer), dont la seule fonction est d'écrire les tampons partagés « modifiés » (dirty shared buffers). Le but est d'éviter aux processus serveur qui gèrent les requêtes utilisateur d'attendre les écritures, le processus d'écriture en arrière-plan se chargeant de celles-ci. Cependant, la charge des entrées/sorties augmente considérablement, parce que si une page fréquemment modifiée n'était auparavant écrite qu'une seule fois par point de vérification, le processus d'écriture en arrière-plan peut l'écrire plusieurs fois dans le même intervalle. Les paramètres décrits dans cette sous-section permettent d'ajuster ce comportement pour des besoins particuliers.
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. 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.
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 (sauf en ce qui concerne l'activité des points de vérification). 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.
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.
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.
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.
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.
Pour des systèmes plus exotiques, comme du stockage mémoire ou un groupement RAID qui serait limité par la bande passante du bus, la valeur correcte pourrait être le nombre de chemins d'entrées/sorties disponibles. Il pourrait être nécessaire d'expérimenter afin d'obtenir la valeur idéale.
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.
Connexions et
authentification