Configuration du serveur

Transcription

1 6 Configuration du serveur Les principaux paramètres de configuration de PostgreSQL se trouvent dans un fichier nommé postgresql.conf. Il est localisé dans le répertoire de base de l arborescence de la base de données. Sur les systèmes Unix, ce répertoire est pointé par la variable d environ nement $PGDATA. Vous pouvez ainsi faire référence au fichier par $PGDATA/ postgresql.conf sur ce type de plates-formes. Ce chapitre reprend la structure de la partie dédiée à ces paramètres de configuration de la documentation officielle 1. Cependant, le discours est orienté vers la recherche des performances. Vous trouverez surtout des recettes pour configurer de façon optimale les paramètres les plus importants plutôt qu une description exhaustive des paramètres. Ce chapitre doit être considéré comme un supplément à la documentation officielle et non pas comme un texte voulant s y substituer. En dehors de la documentation officielle, vous pouvez également consulter l article Tuning Your PostgreSQL Server 2. Certaines informations seront redondantes avec celles que vous allez lire ici. Cependant ce document est mis constamment à jour, de façon à refléter les évolutions de PostgreSQL. Vous pourrez ainsi consulter cet article pour trouver de nombreux détails sur les versions de PostgreSQL qui n existent pas encore au moment où ce livre est écrit. 1. Voir : 2. Cet article est disponible sur le Wiki PostgreSQL : PostgreSQL_Server

2 134 Bases de données PostgreSQL Modification de la configuration à la volée Les possibilités de modifications des paramètres de la base de données sont nombreuses. Outre la modification du fichier de configuration de PostgreSQL et le redémarrage de l instance, il en existe d autres. Si vous les maîtrisez, vous réduirez non seulement le temps d indisponibilité du serveur suite à un changement de configuration, mais vous pourrez aussi vous assurer que vos modifications remplissent leurs objectifs. Valeurs par défaut et valeurs de réinitialisation Dans une base PostgreSQL, le terme par défaut fait référence à deux choses différentes selon le contexte utilisé. D abord, dans le premier contexte d utilisation, les valeurs par défaut correspondent aux valeurs qui seront utilisées par PostgreSQL au démarrage du serveur avant même de lire le fichier postgresql.conf. À partir de PostgreSQL 8.4, vous pouvez obtenir les valeurs par défaut du serveur par le biais de la colonne boot_val de la vue pg_settings 1. Vous avez démarré le serveur, et entretemps vous avez modifié des paramètres. Ces paramètres reprendront leur valeur par défaut si vous utilisez l ordre RESET 2 pour retrouver leur valeur de départ. Cela correspond à la valeur de colonne reset_val de la vue pg_settings. Contextes de modification des paramètres Chaque paramètre de configuration est associé à un contexte dans lequel il peut être modifié. Vous pouvez déterminer ce contexte facilement en interrogeant la base de données. L exemple ci-après vous montre une entrée de chaque type de contexte (si vous exécutez cette requête, vous obtiendrez l ensemble des paramètres de la base) : postgres=# SELECT name,context FROM pg_settings; name context archive_command sihup archive_mode postmaster block_size internal log_connections backend log_min_duration_statement superuser search_path user 1. Voir : 2. Voir :

3 Chapitre 6 Configuration du serveur 135 La colonne context n est pas très bien documentée dans le manuel officiel. La liste suivante vous donne la définition de chaque contexte : internal. Ces paramètres sont principalement configurés au moment de la configuration initiale avant la compilation. Bien qu ils soient inclus dans la vue pg_settings, vous ne pourrez pas les modifier sans recompilation du logiciel. postmaster. Ils ne peuvent être modifiés qu en redémarrant le serveur. Tous les paramètres relatifs à la mémoire partagée sont de cette catégorie. sighup. Si vous envoyez un signal HUP au serveur, il aura pour effet de lui faire relire le fichier postgresql.conf. Tous les changements faits sur ces paramètres seront pris en compte immédiatement. La section suivante vous montre comment faire. backend. Ces paramètres sont, comme la famille sighup, modifiés après relecture du fichier de configuration. Mais les changements n affectent pas les sessions en cours. Seules les nouvelles sessions prendront ces changements en compte. Il n y a pas beaucoup de paramètres de ce type. La plupart d entre eux ne seront pris en compte que lorsque l on commence ou arrête une session. L exemple ci-dessus indique que log_connections est de ce type (ce paramètre sert à indiquer à PostgreSQL de tracer les nouvelles connexions). On imagine sans difficultés que ce paramètre n a aucun effet rétroactif sur les connexions déjà réalisées, seules les connexions ultérieures seront tracées. superuser. Ils ne sont modifiés que par des superutilisateurs de la base de données à n importe quel moment. Les changements sont effectifs immédiatement sans même devoir recharger la configuration. La plupart des paramètres de cette catégorie sont relatifs aux fonctionnalités de traces des requêtes exécutées par le serveur. user. Ces paramètres peuvent être modifiés dynamiquement par un utilisateur au niveau de la session courante. Dans ce cas le changement n affectera pas les autres sessions. Ils peuvent aussi surcharger les paramètres lus dans le fichier de configuration pour un utilisateur donné 1. Dans ce dernier cas, chaque fois que l utilisateur se connecte, les paramètres concernés prendront la valeur donnée au niveau utilisateur, parfois pour une base de données particulière. Comme vous pouvez sans doute le déduire à partir de cette liste, la réponse à une question de la forme : Quelle est la valeur actuelle de work_mem? peut avoir plusieurs réponses en fonction de votre identité dans la base et du contexte utilisé. Un paramètre est en effet initialisé avec la valeur correspondante tirée du fichier postgresql.conf. 1. L ordre ALTER ROLE nom SET vous permet de faire cela. Voir la documentation :

4 136 Bases de données PostgreSQL Puis sa valeur par défaut est modifiée en rechargeant la configuration. Et enfin elle peut être modifiée encore une fois dans une session qui a besoin de changer un paramètre particulier avant d exécuter une requête. INFO Le superutilisateur est l utilisateur qui a créé la base, en général postgres. Recharger le fichier de configuration Vous disposez de trois façons pour forcer le rechargement du fichier de configuration par PostgreSQL et mettre à jour les valeurs de la famille sighup. La fonction système pg_reload_conf() est une première méthode, à condition de se connecter comme superutilisateur : postgres=# SELECT pg_reload_conf(); pg_reload_conf t La commande Unix kill vous permet d envoyer un signal SIGHUP au serveur : $ ps -eaf grep postgres -D postgres :21 pts/0 00:00:00 /home/postgres/inst/bin/ postgres -D / home/postgres/data/ $ kill -HUP Vous pouvez encore déclencher un signal SIGHUP au serveur par le biais de la commande pg_ctl : $ pg_ctl reload server signaled Peu importe la méthode, PostgreSQL émettra le message suivant dans ses fichiers de trace : LOG: received SIGHUP, reloading configuration files Pour vous assurer que les modifications ont bien été prises en compte, utilisez l ordre SHOW ou en interrogeant la vue pg_settings. Paramètres décommentés Que se passe-il lorsque vous avez modifié vous-même un paramètre puis que vous le désactivez, en le commentant dans le fichier postgresql.conf, sur un serveur déjà démarré? La réponse dépend de la version de PostgreSQL utilisée.

5 Chapitre 6 Configuration du serveur 137 Admettons que vous ayez préalablement modifié le paramètre suivant dans le postgresql.conf : checkpoint_segments = 30 Vous éditez ensuite le fichier de façon à commenter ce paramètre en le préfixant du caractère dièse : #checkpoint_segments = 30 Puis vous demandez au serveur de recharger sa configuration : $ pg_ctl reload Le paramètre checkpoint_segment est placé dans le contexte sighup. À partir de PostgreSQL 8.3, un tel changement verra le paramètre reprendre la valeur par défaut du serveur (boot_val). Et à partir de la version 9.0, ce changement sera enregistré dans le fichier de trace : LOG: received SIGHUP, reloading configuration files LOG: parameter checkpoint_segments removed from configuration file, reset to default Vous pouvez confirmer le changement avec l ordre SHOW : $ psql -x -c show checkpoint_segments -[ RECORD 1 ] checkpoint_segments 3 Mais si vous utilisez PostgreSQL 8.2 ou une version antérieure, aucun changement ne se produira : checkpoint_segments sera toujours positionné à 30. Il faudra redémarrer le serveur pour qu il reprenne sa valeur par défaut de 3. Ce comportement complexe, qui dépend des versions, oblige les administrateurs PostgreSQL, même les plus expérimentés, à vérifier par deux fois qu un paramètre modifié a bien été pris en compte, soit en utilisant SHOW, soit en interrogeant pg_settings. Toujours depuis la version 8.2, il est possible d inclure des fichiers de configuration additionnels à partir du fichier postgresql.conf principal, grâce à la directive include 1. Le fichier est ensuite chargé comme si vous aviez inséré son contenu à l endroit où vous l avez inclus. La vue pg_settings vous permet toutefois de déterminer le fichier qui a permis de positionner tel paramètre. Elle indique d ailleurs à quelle ligne il a été modifié. Par ailleurs, si un paramètre est positionné plusieurs fois, seule la dernière valeur lue sera prise en compte. 1. Voir :

6 138 Bases de données PostgreSQL Paramètres au niveau serveur Dans certains cas, ces paramètres peuvent être modifiés dans d autres contextes. Mais en général, ceux qui sont évoqués ici ne peuvent être modifiés que par le fichier postgresql.conf avant le démarrage du serveur. Connexions aux bases de données Un certain nombre de paramètres de configuration contrôlent la façon dont les utilisateurs peuvent se connecter, soit à distance, soit en local, à la base de données. La liste complète de ces paramètres est disponible dans le manuel : docs/current/runtime-config-connection.html. listen_addresses Il vous faudra modifier listen_adresses de façon à ce qu une instance puisse être utilisée à distance. Sa valeur par défaut n autorise que les connexions locales, c est-àdire des utilisateurs qui sont connectés sur le même serveur que l instance de base de données. On le configure en général de façon à écouter sur toutes les interfaces du système, de cette manière : listen_addresses = * Ensuite, vous pouvez configurer le fichier pg_hha.conf pour contrôler finement les droits d accès. La documentation décrit comment le faire : auth-pg-hba-conf.html. Cette façon de procéder peut potentiellement poser des problèmes de performances. Il peut être en effet moins coûteux de configurer plus finement listen_addresses plutôt que de laisser les clients se connecter et ensuite valider leur connexion par rapport au contenu du pg_hba.conf. Non seulement, vous consommerez plus de ressources, mais vous laisserez aussi la possibilité à des utilisateurs malicieux de provoquer un déni de service par cette voie. En pratique, très peu de serveurs PostgreSQL sont exposés directement sur Internet. En général, les accès réseaux sur le port par défaut de PostgreSQL (5432) sont filtrés au niveau des firewalls. Ce premier niveau de sécurité est certainement l approche la plus efficace et elle permet en plus de sécuriser d autres applications. Comme c est souvent le cas pour les bases de données hébergées en mode cloud, vos systèmes sont accessibles à tout le monde. Dans ce cas, assurez-vous de bien utiliser les trois niveaux de défense suivants : restreignez les accès au niveau du firewall, réduisez au strict minimum la liste des adresses d écoute de PostgreSQL et enfin restreignez finement les accès aux bases de données en utilisant le fichier pg_hba.conf.

7 Chapitre 6 Configuration du serveur 139 max_connections Vous trouverez ce paramètre systématiquement configuré, en général à 100, dans le fichier postgresql.conf. Le programme initdb lui assigne sa valeur initiale. Nous l avons expliqué au chapitre précédent : chaque connexion utilise une petite quantité de mémoire partagée. Il est donc possible que votre système ait des limites par défaut d allocation de mémoire partagée. De ce fait, il n est même pas possible d allouer suffisamment de mémoire pour tenir autant de connexions. En conséquence, à la création de l instance, initdb détermine la valeur la plus élevée possible, en se limitant à un maximum de 100 connexions possibles. Cette valeur est alors sauvegardée dans le fichier de configuration, comme initdb le fait aussi pour shared_buffers. Il est important de ne pas positionner une valeur trop élevée par rapport à vos besoins réels. Ce paramètre influence en effet la consommation de ressources. S il est trop élevé, il utilisera bien entendu plus de mémoire partagée. Et généralement c est la dernière des choses dont vous aurez à vous préoccuper si vous garder une valeur raisonnable à ce paramètre. Mais un client peut utiliser d autres ressources et notamment allouer de la mémoire pour les tris (contrôlée par le paramètre work_mem, voir plus bas). Si ce paramètre est configuré avec une valeur élevée, il est plus prudent de diminuer ce paramètre pour éviter de consommer trop de mémoire. INFO Les systèmes Windows imposent une limitation d allocation de ressources qui vous empêche d avoir plus de 125 connexions simultanées. Un article du Wiki décrit le problème et vous propose des solutions : On_Native_Windows. Il faut néanmoins bien comprendre qu établir une connexion à PostgreSQL consomme beaucoup de ressources. Dans une base de données, le travail d établissement d une connexion et d authentification, jusqu à atteindre le point où le client peut exécuter une requête, est une opération très coûteuse. Les connexions commencent à devenir coûteuses et dégradent les performances du systèmes quand le serveur doit gérer plusieurs centaines de connexions. Le seuil exact dépend par ailleurs fortement du matériel et de la configuration. Certes, si votre système doit exécuter des centaines de requêtes concurrentes, la solution n est pas d autoriser chaque client à se connecter directement à la base. Vous pouvez placer un système de multiplexage de connexions entre l application et la base de données de façon à éviter de vous retrouver face à un point de contention. Reportez-vous au Chapitre 13 pour plus de détail sur cette technique.