Configuration du serveur

Transcription

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 officielle1. 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 Server2”. 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 : http://docs.postgresql.fr/current/runtime-config.html
2.Cet article est disponible sur le Wiki PostgreSQL : http://wiki.postgresql.org/wiki/Tuning_Your_
PostgreSQL_Server
© 2011 Pearson Education France – Bases de données PostgreSQL – Gregory Smith
Book_PostgreSQL.indb 133
18/04/11 17:35
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_settings1.
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 RESET2 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 : http://docs.postgresql.fr/current/view-pg-settings.html
2. Voir : http://docs.postgresql.fr/current/sql-reset.html
18/04/11 17:35
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
vous ne pourrez pas les modifier sans recompilation du logiciel.
pg_settings,
■■ 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 : http://docs.postgresql.fr/current/sql-alterrole.html
18/04/11 17:35
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 11185
1 0 22:21 pts/0 00:00:00 /home/postgres/inst/bin/ postgres -D /
➥ home/postgres/data/
$ kill -HUP 11185
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.
18/04/11 17:35
Chapitre 6
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 include1.
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 : http://docs.postgresql.fr/current/runtime-config.html#config-setting
18/04/11 17:35
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 : http://docs.postgresql.fr/
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 : http://docs.postgresql.fr/current/
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.
18/04/11 17:35
Chapitre 6
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 : http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_
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.
18/04/11 17:35

Configuration du serveur

Transcription

Documents pareils

Sauvegarde / Restauration d`une Base Postgresql

Liaison ODBC - jchambon.fr

Table des matières 1 Installation 2 Configuration

Développeur Web (PHP/MySQL+PostgreSQL)

CV - Julien Vaudour

Formation POSTGRESQL, la haute disponibilité

Performances PostgreSQL au niveau du système

Installation du Driver JDBC pour PostgreSQL