Un peu de soin et de préparation de votre déploiement PostgreSQL contribuent grandement à garantir les performances, à éviter les découvertes désagréables et à établir une prévisibilité fiable. Voici 7 choses sur lesquelles vous devriez garder un œil.
Tableau gonflé
PostgreSQL implémente les transactions à l'aide d'une technique appelée MVCC. MVCC est trop long et implique un sujet à discuter en détail, mais il y en atrois les choses que vous devez savoir à ce sujet :
- La suppression d'une ligne la marque uniquement comme "invisible" pour les futures transactions.
- La mise à jour d'une ligne crée une nouvelle version de la ligne. L'ancienne version est marquée comme invisible pour les futures transactions et la nouvelle version est marquée comme visible.
- Périodiquement, quelqu'un doit examiner toutes les transactions en cours d'exécution et dire :OK, la transaction la plus ancienne ici est la n°42, donc chaque version de ligne qui est invisible pour la n°42 peut être physiquement supprimée sans nuire à la cohérence des données.
C'est ainsi que fonctionne MVCC (essentiellement), et l'implication est que les mises à jour seront augmenter votre empreinte physique de stockage de base de données, et les suppressions ne le feront pas Réduisez-le. MVCC ressemble à une façon paresseuse de faire les choses, mais il est populaire car il offre à la fois cohérence et performances.
Les versions de ligne indésirables et obsolètes dans une table sont appelées bloat (ou deadrows ). Le processus qui peut éliminer les ballonnements s'appelle vacuum . PostgreSQL possède un processus de vide déclenché automatiquement avec des seuils réglables appelé autovacuum, et bien sûr la commande VACUUM.
En général, le gonflement peut également ralentir les requêtes en raison de cartes de visibilité inexactes et d'E/S de disque gaspillées.
Pour cette raison, vous devez régulièrement :
- surveiller la quantité de gonflement dans une base de données
- faites l'aspirateur régulièrement
- surveiller si le vide est exécuté régulièrement pour toutes les tables
Il existe quelques requêtes SQL pour fournir une estimation du gonflement par table. L'outil open source pgmetrics fournit des estimations de ballonnement ainsi que les dernières durées d'exécution du vide manuel et automatique.
Bouffée d'index
Les index peuvent aussi gonfler. Bien que la structure interne des index soit opaque pour l'utilisateur SQL et varie selon le type d'index (BTree, hash, GIN, GIST, etc.), l'idée générale demeure que lorsque des lignes référencées par l'index sont supprimées, l'espace occupé par les informations associées à l'intérieur de l'index n'est supprimé que logiquement et n'est pas renvoyé au système de fichiers. L'espace logiquement supprimé peut être réutilisé ultérieurement par l'index.
Il existe deux manières de faire en sorte que Postgres réduise la taille physique d'un index :
- la version COMPLÈTE de la commande VACUUM
- RÉINDEX
Le gonflement de l'index doit être surveillé, de sorte que vous soyez au moins conscient de la quantité d'espace restant inutilisé. Dans les tables avec une rotation élevée des lignes, il n'est pas rare de configurer des tâches de reconstruction d'index régulières.
Le gonflement de l'index peut également être obtenu par les mêmes requêtes qu'auparavant, et également via pgmetrics.
Transactions de longue durée
Les transactions doivent être aussi courtes que possible, en particulier dans un système MVCC.
Imaginez qu'une transaction ait commencé hier et qu'il y ait eu un vide juste après. Maintenant, tant que cette transaction est ouverte, d'autres vides sont inutiles, puisque par définition, notre transaction devra voir toutes les lignes de toutes les tables telles qu'elles étaient lorsque notre transaction a commencé hier. Même si notre transaction est en lecture seule, c'est toujours le cas.
En conséquence, les transactions de longue durée créent un gonflement. Ils s'accrochent également aux ressources du système, maintiennent les verrous non abandonnés et augmentent les risques de blocages.
La meilleure façon de garder un œil sur les transactions de longue durée consiste à configurer une alerte pour le nombre de transactions exécutées depuis plus d'une certaine durée. Vous pouvez l'obtenir à partir de la vue des statistiquespg_stat_activity , comme ceci :
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Délai de réplication
Lorsque la réplication en continu est utilisée pour répliquer toutes les modifications d'un serveur PostgreSQL primaire vers un serveur de secours (également appelé réplica en lecture), il y a généralement un léger délai entre le moment où les mises à jour des lignes se produisent sur le serveur principal et le moment où les modifications sont visibles pour les applications connectées au serveur de secours. .
Il existe cependant des cas où ce décalage peut augmenter :
- le système de secours est incapable de recevoir et d'appliquer les modifications du système principal assez rapidement pour le suivre, généralement en raison d'une charge élevée ou d'un sous-provisionnement
- un réseau ou un disque dégradé
- conflits de requête
Une veille avec un décalage de réplication élevé, voire pire, croissant, peut entraîner des requêtes sur la veille renvoyant des données obsolètes et une veille inapte au basculement.
Si vous avez une configuration de réplication en continu, la surveillance des décalages de réplication entre chaque paire primaire-de secours est très importante, et vous souhaiterez configurer des alertes pour vérifier si les décalages de réplication dépassent une minute, ou tout autre seuil adapté à votre configuration.
Cet article contient beaucoup plus d'informations sur la façon de mesurer et de surveiller le décalage de réplication des extrémités principale et de secours.
Emplacements de réplication inactifs
L'utilisation de slots de réplication, introduite dans PostgreSQL 9.4, rend la réplication en continu plus robuste et efficace. Essentiellement, le serveur de secours signale la progression de la réplication au serveur principal, qui stocke ces informations dans le "slot de réplication".
De ce fait, le primaire sait désormais à tout moment à quel point le standby est en retard. Cela permet au primaire de conserver un backlog suffisant de fichiers WAL (qui sont nécessaires pour reprendre la réplication) lorsque le standby se déconnecte. Ainsi, lorsque le standby revient, même après un long moment, le primaire peut toujours garantir que la réplication pourra reprendre.
Avant les slots de réplication, le primaire peut nettoyer les anciens fichiers WAL, car il n'avait aucun moyen de savoir si ses standby en avaient besoin ou non. Si un fichier WAL requis par astandby est supprimé, il n'y a aucun moyen de reprendre la réplication; il doit être reconfiguré à partir de zéro.
Cependant, le comportement du primaire consistant à conserver les fichiers WAL indéfiniment conduit à un autre problème. Si un standby a été retiré et que le slot de réplication associé n'a pas été supprimé, les fichiers WAL seront conservés pour toujours. Les fichiers WAL conservés pour cette raison ne sont pas soumis aux limites fixées par max_wal_size et d'autres options de configuration.
Cette situation persistera jusqu'à ce que les fichiers WAL consomment tout l'espace disque, sans même un avertissement dans les fichiers journaux de PostgreSQL.
Inutile de dire que les slots de réplication inactifs doivent être traités lorsqu'ils sont détectés. Trouvez vos slots de réplication inactifs en utilisant :
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analyser le statut
ANALYZE est exécuté sur des tables pour collecter et mettre à jour des informations statistiques sur le contenu de la table. Ces informations sont utilisées par le planificateur de requêtes pour préparer le plan d'exécution de chaque requête SQL. Des statistiques à jour sur le contenu de la table permettent d'améliorer le plan d'exécution, ce qui se traduit par une requête plus rapide.
Le démon autovacuum exécute généralement ANALYZE après VACUUM. Cependant, cela peut ne pas être assez fréquent pour ANALYZE. Si la distribution des données dans un tableau changent souvent, vous devriez exécuter ANALYZE plus fréquemment.
En règle générale, ANALYZE se comporte plutôt bien - il ne nécessite que des verrous en lecture, n'utilise pas trop de ressources et se termine dans un délai raisonnable. Il est prudent de l'utiliser plus souvent qu'autrement.
Garder un œil sur les tables qui n'ont pas été ANALYSÉES depuis un certain temps est une bonne idée. Découvrez la dernière fois que vos tables ont été (auto-)analysées avec la requête :
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Utilisation des ressources
La surveillance de la charge du processeur, de la mémoire et de l'utilisation du disque contribue grandement à garantir que vous disposerez d'une capacité suffisante pour répondre aux besoins croissants des applications utilisant votre base de données.
PostgreSQL génère un processus pour gérer une connexion. Bien qu'il ne s'agisse pas de l'architecture la plus évolutive de nos jours, elle contribue beaucoup à la stabilité. Cela rend également la charge moyenne du système d'exploitation plus significative. Comme d'habitude les PostgreSQLbox n'exécutent que PostgreSQL, une moyenne de charge de 3, par exemple, signifie généralement qu'il y a 3 connexions attendant que les cœurs de processeur soient disponibles pour pouvoir être programmés. La surveillance de votre moyenne de charge maximale au cours d'une journée ou d'une semaine typique peut donner une estimation de la sur- ou sous-provisionnement de votre boîtier sur le front du processeur.
La mémoire et l'espace disque disponible sont bien sûr des éléments standard à surveiller. Plus de connexions et des transactions plus longues sollicitent davantage la mémoire. Et tout en surveillant l'espace disque libre, n'oubliez pas de le suivre par tablespace.
