L'un des éléments les plus utiles de
la documentation PostgreSQL sur laquelle j'ai travaillé est le réglage de votre serveur PostgreSQL
. Lorsque cela a été écrit à l'été 2008, quelques mois après la sortie de PostgreSQL 8.3, il était difficile de trouver un guide similaire qui soit à la fois (relativement) concis et à jour. Depuis lors, moi-même et
de nombreux autres contributeurs de PostgreSQL ont contribué à maintenir ce document à jour
à mesure que des modifications ont été apportées à PostgreSQL.
La tendance intéressante et utile
au cours de cette période est que les paramètres continuent de disparaître de l'ensemble
de ceux dont vous devez vous soucier. Dans PostgreSQL 8.2, il y avait une longue
liste de paramètres dont vous aviez probablement besoin pour ajuster les performances
sur un serveur PostgreSQL : shared_buffers, effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers et (si vous utilisez
le partitionnement) restrict_exclusion.
La version 8.3 a activé l'autovacuum par défaut
avec un comportement raisonnable, tout en supprimant quelques-uns
Paramètres d'écriture en arrière-plan qui n'ont causé que des problèmes (ils
n'ont jamais fait partie de la liste). La version 8.4 supprimait le besoin des deux paramètres
max_fsm_*, augmentait default_statistics_target à une bien meilleure valeur de départ et rendait inutile la définition de la contrainte_exclusion
dans les cas les plus courants. C'est six paramètres de moins
que vous devrez probablement ajuster.
Malheureusement, la version 9.0 n'a fait que
compliquer la configuration du serveur. Et les nouveaux noyaux Linux
ont même repoussé le comportement par défaut. À partir du noyau Linux
2.6.33, la valeur par défaut choisie pour wal_sync_method est devenue
open_datasync. Cela s'avère avoir de terribles
implications sur les performances pour PostgreSQL, en particulier lorsqu'il est combiné avec le paramètre par défaut bas pour wal_buffers dans le serveur.
Mais la marche vers un meilleur comportement par défaut
a récemment repris pour ce qui est finalement prévu d'être
PostgreSQL 9.1. Au cours du dernier CommitFest, un correctif créé par Marti
Raudsepp pour résoudre le problème de wal_sync_method a été validé
après quelques discussions intenses sur la forme que ce changement devrait prendre.
Découvrir que ce changement de comportement a complètement cassé PostgreSQL
lors de l'exécution sur ext4 avec l'option "data=journal" aidé
à régler la bonne chose à faire ici par défaut.
Deux paramètres que je déconseille
de toucher dans la plupart des cas sont commit_siblings et commit_delay,
artefacts d'une ancienne tentative d'amélioration des performances sur les systèmes avec des temps de validation lents (ce qui inclut la plupart des systèmes qui n'ont pas de cache en écriture avec batterie de secours pour accélérer ce domaine). De nos jours
la désactivation du paramètre synchronous_commit introduit dans la version 8.3 est
plus susceptible d'aider ici. Bien qu'il soit peu probable qu'ils améliorent
les performances, les personnes qui essaient de les configurer ont souffert plus que
nécessaire des inconvénients de cette décision. Le comportement
dans le pire des cas a été considérablement amélioré dans un patch que j'ai écrit pour optimiser l'exécution de la logique que ces paramètres contrôlent.
Et cette semaine, le dernier paramètre à
être effectivement éliminé dans la plupart des cas est wal_buffers. Un changement que j'ai
suggéré a été commis pour définir cela automatiquement comme un pourcentage de la taille (environ 3%)
alloué aux paramètres de shared_buffers normalement beaucoup plus grands.
Cela définit la valeur de wal_buffers sur la limite supérieure normale de sa plage effective, 16 Mo, une fois que vous avez alloué au moins 512 Mo aux
shared_buffers. Et si vous avez augmenté la valeur de shared_buffers par rapport à sa petite
valeur par défaut, vous obtiendrez une amélioration correspondante de cet important paramètre de performance de validation. Vous devrez faire tout votre possible pour casser le réglage de ce paramètre afin de tomber dans les mauvaises
situations possibles dans les versions antérieures.
Avoir la quantité de configuration que vous
devez faire pour le serveur par défaut devient moins compliqué est toujours
valable, et voir des paramètres disparaître de la liste critique est
un changement bienvenu. Et après? Les principaux problèmes liés à l'allocation de
mémoire partagée sur les systèmes d'exploitation dérivés d'UNIX, en particulier Linux,
rendent très difficile l'élimination des buffers_partagés. Et les inquiétudes
sur le fait que le serveur prenne en charge le système limitent la capacité
à définir automatiquement des paramètres tels que work_mem dans la bonne plage.
Certaines propositions pour une meilleure gestion du pool de mémoire de travail ont été
suggéré, afin que l'on puisse voir une certaine amélioration.
Le prochain paramètre sur lequel j'ai un œil est
checkpoint_segments. Après avoir ajouté juste une journalisation supplémentaire dans ce domaine lors du
dernier CommitFest, il y a quelques améliorations dans ce domaine qui approchent
commit maintenant pour réellement améliorer le comportement des points de contrôle. J'espère
éventuellement basculer sur le réglage des points de contrôle pour qu'il soit strictement contrôlé
via des paramètres temporels, plutôt que d'exiger des utilisateurs
comprendre les mécanismes de fonctionnement du journal d'écriture anticipée pour régler le
br /> système. Il y a encore trop de situations désagréables possibles ici pour le faire
à temps pour la 9.1, mais la définition automatique du nombre de segments est
possible de cibler pour la 9.2.
