PostgreSQL et performances
La performance est l'une des principales exigences de la conception d'architecture logicielle et a été au centre des préoccupations des développeurs PostgreSQL depuis ses débuts, également illustrée dans le commit suivant des sources PostgreSQL Git :
commit d31084e9d1118b25fd16580d9d8c2924b5740dff
Author: Marc G. Fournier <[email protected]>
Date: Tue Jul 9 06:22:35 1996 +0000
Postgres95 1.01 Distribution - Virgin Sources
[...]
diff --git a/src/backend/access/heap/stats.c b/src/backend/access/heap/stats.c
new file mode 100644
index 0000000000..d41d01ac1b
--- /dev/null
+++ b/src/backend/access/heap/stats.c
@@ -0,0 +1,329 @@
+/*-------------------------------------------------------------------------
+ *
+ * stats.c--
+ * heap access method debugging statistic collection routines
+ *
+ * Copyright (c) 1994, Regents of the University of California
[...]
+ * Also note that this routine probably shouldn't have to exist, and does
+ * screw up the call graph rather badly, but we are wasting so much time and
+ * system resources being massively general that we are losing badly in our
+ * performance benchmarks.
+ */
PostgreSQL atteint des performances en implémentant diverses fonctionnalités :
- Plusieurs types d'index
- Planificateur et optimiseur de requêtes pouvant tirer parti des systèmes multiprocesseurs
- MVCC
- Partitionnement de table
Sélection de l'environnement
Avec les nombreuses options disponibles aujourd'hui, de nombreuses questions se posent :
- Sur site ou dans le cloud ?
- Bare metal ou virtualisé ?
- Matériel de marque ou construit par vous-même ?
- Comment les fonctions de bas niveau PostgreSQL ou fsync affectent-elles les performances matérielles ?
- Disque local ou espace de stockage partagé ?
- Quels paramètres de système d'exploitation doivent être définis ?
Encore une fois, le wiki PostgreSQL est un très bon point de départ pour tout ce qui concerne les performances.
Quels sont les principaux éléments à rechercher ?
Étant donné qu'il existe de nombreuses publications sur divers aspects de l'optimisation des performances de PostgreSQL et de la conception du système (indice :recherchez xfs sur la page), ce blog n'est pas censé être une plongée approfondie dans l'un des sujets déjà abordés, mais plutôt un Le point de vue de l'administrateur système sur le point de départ lorsque l'objectif principal est d'éviter les conflits de ressources. Je soulignerai également de nombreuses références qui traitent de questions spécifiques plus en détail. Des conseils d'experts dans tous les domaines critiques pour les performances de PostgreSQL sont disponibles auprès des nombreuses sociétés proposant des services professionnels.
Commençons !
Collecte d'informations
En supposant une installation par défaut, et sachant que PostgreSQL n'essaie pas d'être bien réglé dès le départ et qu'il peut même y avoir quelques bizarreries, cette étape implique la configuration des outils de surveillance nécessaires.
Une bonne surveillance est essentielle pour comprendre l'application et être en mesure de localiser rapidement les ressources affectées, et cela est particulièrement vrai pour les fournisseurs de cloud où l'accès à l'hôte de la base de données peut ne pas être disponible afin d'exécuter des tests de performances pour le processeur ou les E/S :
Fig.1 — SlideShare, Jignesh Shah, Meilleures pratiques avec PostgreSQL géré dans le cloudRéagir aux alertes de performances du système
Les outils de surveillance afficheront des graphiques et des alertes sur les indicateurs de performance du système :
Processeur :
- Alerte :une utilisation élevée indique une requête de longue durée.
- Impact :temps de réponse de l'application.
- Action – Examinez les métriques des statistiques de la base de données pour identifier les requêtes qui doivent être ajustées.
E/S :
- Alerte – Nombre élevé ou lectures.
- Impact :temps de réponse de l'application.
- Action :ajoutez un autre réplica en lecture. Examinez les métriques des statistiques de la base de données pour identifier les requêtes de longue durée.
- Alerte :nombre élevé d'écritures.
- Impact :temps de réponse de l'application.
- Action :ajustez les paramètres GUC shared_buffers, work_mem et maintenance_work_mem. Réglez le pointeur de contrôle et assurez-vous que le vide automatique est correctement réglé. Si PostgreSQL est installé sur votre propre matériel, configurez les espaces de table et/ou envisagez le partitionnement, mais comprenez les mises en garde concernant le partitionnement.
Mémoire :
- Alerte :utilisation élevée de la mémoire.
- Impact :performances d'E/S
- Action – Examinez les métriques des statistiques de la base de données pour identifier les requêtes qui doivent être ajustées.
Réseau :
- Alerte :latence élevée. Il s'agit généralement d'un problème DBaaS.
- Impact :clients, réplication
- Action – Rapprocher les hôtes de base de données des serveurs frontaux.
- Alerte :nombre élevé de connexions.
- Impact — Clients.
- Action – Envisagez d'utiliser l'interrogation de connexion.
Indicateurs de performance internes de la base de données
Les vues pg_* sont la fenêtre sur les performances du moteur de base de données, et les applications de gestion PostgreSQL ont été écrites pour aider à corréler la richesse des informations autrement disponibles via diverses requêtes SQL. Des extensions supplémentaires existent et elles sont souvent intégrées ou disponibles sous forme de plugins.
L'utilisation de tels outils simplifie la tâche de l'administrateur de base de données et garantit que les meilleures pratiques sont suivies lors de l'installation et de la configuration du cluster de bases de données.
Statistiques de la base de données
Les outils de surveillance tels que ClusterControl utilisent les statistiques d'activité de la base de données pour aider le DBA à régler les performances :
Fig.2 — Plusieurs neuf, éléments clés à surveiller dans PostgreSQL — Analyse de votre charge de travailTélécharger le livre blanc aujourd'hui PostgreSQL Management &Automation avec ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blancOptimisation des requêtes
À partir de la version 9.5, PostgreSQL inclut des améliorations considérables des performances des requêtes telles que les index BRIN et les requêtes parallèles :
Fig.3 — 2ndQuadrant, Thomas Vondra, Améliorations des performances dans PostgreSQL 9.5 (et au-delà)Verrouillage
Concurrency Control est dédié à un chapitre entier dans la documentation PostgreSQL. Utilisez des outils de surveillance pour être alerté lorsque le nombre de verrous ou la durée du verrou dépasse le seuil et résolvez le problème en recherchant les index manquants, en examinant le code de l'application ou en passant à l'interrogation de connexion.
Chargement groupé
synchronous_commit peut être désactivé lors d'importations de données volumineuses. D'autres options sont présentées dans la section de la documentation PostgreSQL Remplir une base de données.
Conclusion
Le réglage des performances de PostgreSQL est une tâche complexe. La complexité vient des nombreux paramètres mis à disposition, ce qui est un argument de poids en faveur de PostgreSQL. Il n'y a pas de solution miracle pour résoudre les problèmes de performances, ce sont plutôt les spécificités de l'application qui dictent en fin de compte les exigences de réglage. Par conséquent, les outils de surveillance peuvent aider à obtenir des informations sur les performances par rapport aux performances du système et permettent en outre d'identifier les domaines spécifiques à PostgreSQL qui nécessitent un réglage ainsi que les requêtes SQL qui nécessitent une optimisation. De plus, les systèmes de gestion de base de données peuvent aider à la configuration et à l'administration de PostgreSQL afin de s'assurer que les meilleures pratiques sont suivies.