Informations Snowflake Postgres¶

Réussite du cache¶

Postgres essaie généralement de conserver les données auxquelles vous accédez le plus souvent dans son cache de mémoire tampon partagée. Le ratio de réussite du cache mesure le nombre de demandes de contenu que le cache de la mémoire tampon est en mesure de traiter par rapport au nombre de requêtes qu’il reçoit. Une réussite du cache correspond à une requête qui est traitée correctement, tandis qu’un échec du cache correspond à une requête qui ne l’est pas. Un échec du cache ira au-delà du cache pour atteindre le système de fichiers afin de répondre à la requête.

Ainsi, si vous avez 100 réussites du cache et 2 échecs du cache, vous aurez un ratio de réussite du cache de 100/102, ce qui équivaut à 98 %.

Pour les opérations normales de Postgres et des performances, vous souhaiterez que votre ratio de réussite du cache Postgres soit d’environ 99 %.

Si vous constatez que votre ratio de réussite du cache est inférieur à ce pourcentage, vous devrez peut-être envisager de passer à une instance dont la mémoire est plus grande.

Réussite des index¶

L’ajout d’index à votre base de données est essentiel aux performances des requêtes et des applications. Les index sont particulièrement utiles dans les grandes tables.

Le taux de réussite des index est mesuré sous la forme d’un ratio ou d’un pourcentage du nombre total de requêtes ou d’exécutions de requêtes qui utilisent correctement un index par rapport au nombre total de requêtes exécutées. Un taux de réussite des index plus élevé suggère une meilleure utilisation des index et de meilleures performances globales des requêtes.

En général, vous recherchez plus de 99 % sur des tables de plus de 10 000 lignes. Si vous voyez une table de plus de 10 000 lignes sans ou avec peu d’utilisation des index, cela signifie que vous devriez commencer à ajouter un index.

Index inutilisés¶

Les index non utilisés dans PostgreSQL font référence à des index créés sur des tables, mais qui ne sont pas activement utilisés. Ces index consomment de l’espace disque, nécessitent une maintenance, et peuvent affecter négativement les performances.

Voici quelques raisons pour lesquelles vous devriez vous soucier des index inutilisés dans Postgres :

• Stockage et espace disque : Les index non utilisés occupent un espace disque qui pourrait être mieux utilisé à d’autres fins. Cela peut entraîner une augmentation des coûts de stockage et réduire l’espace disponible pour les autres objets de la base de données.

• Impact sur les performances : Les index entraînent des frais généraux lors des opérations de modification des données, telles que les insertions, les mises à jour et les suppressions. Lorsqu’il existe de nombreux index inutilisés, ces opérations prennent plus de temps, car la base de données doit mettre à jour plusieurs index en plus de la table.

• Exécution des requêtes plus lente : L’optimiseur de requêtes de Postgres prend en compte tous les index disponibles lors de la génération d’un plan d’exécution pour une requête. S’il existe des index non utilisés, l’optimiseur peut consacrer plus de temps à l’examen de ces index, ce qui entraîne des plans de requête sous-optimaux et une exécution plus lente des requêtes.

• Frais généraux de maintenance : La maintenance des index nécessite des ressources, notamment au niveau du CPU et des E/S disque. Si vous avez un grand nombre d’index inutilisés, ces ressources sont gaspillées pour des tâches inutiles de maintenance des index.

Bloat¶

Le bloat fait référence à l’accumulation de lignes obsolètes et inutilisées dans une base de données, ce qui entraîne une consommation d’espace disque et une dégradation des performances. Il affecte principalement les bases de données avec des charges de travail de transactions élevées. Le système MVCC de Postgres crée plusieurs versions d’une ligne pour gérer les transactions simultanées. Lorsqu’une ligne est mise à jour ou supprimée, une nouvelle version est créée, tandis que l’ancienne version est marquée comme obsolète. Ces lignes obsolètes ne sont pas immédiatement supprimées de la table pour préserver l’intégrité transactionnelle et assurer la cohérence des données lors des opérations simultanées.

Pour récupérer l’espace disque occupé par des lignes obsolètes, Postgres effectue périodiquement un nettoyage. Ce processus identifie et élimine les lignes mortes de la table, libérant l’espace disque à des fins de réutilisation. Le bloat se produit lorsque des transactions élevées génèrent un nombre important de lignes obsolètes entre les processus de nettoyage.

Nous fournissons un pourcentage de bloat pour montrer la quantité d’espace occupée par des lignes obsolètes par rapport à la taille totale de la table ou de l’index. Le bloat affiché est une estimation ou une approximation. Si vous avez besoin de plus de données sur le bloat dans vos tables, vous pouvez utiliser l’extension pgstattuple, bien qu’il puisse s’agir d’une opération exigeante en matière de ressources.

Bloat bas : Un bloat inférieur à 50 % est généralement considéré comme acceptable et ne nécessite normalement pas d’actions. Il est toujours recommandé de surveiller le bloat pour voir s’il continue à augmenter et de contrôler les configurations et les paramètres de nettoyage.

Bloat élevé : Un bloat supérieur à 50 % suggère un niveau élevé de bloat qui peut commencer à avoir un impact important sur les performances et l’utilisation de l’espace disque. Vous devrez peut-être envisager des actions, telles que l’exécution d’une opération manuelle de nettoyage ou la modification des paramètres de nettoyage, si vous remarquez des requêtes lentes ou des problèmes de performances.

Nous n’affichons pas de pourcentage de bloat pour les tables en dessous d’1GB ou avec un pourcentage de bloat inférieur à 10 %.

Requêtes inhabituelles¶

Il s’agit des requêtes dont le temps d’exécution proportionnel est le plus élevé. Cela peut inclure des requêtes très lentes, mais relativement peu fréquentes, ainsi que des requêtes légèrement lentes, mais extrêmement courantes. Les requêtes dont le temps d’exécution proportionnel est le plus élevé constituent le meilleur point de départ pour le réglage des requêtes de base de données au niveau de l’application ou pour l’indexation.

Requêtes de longue durée¶

Les requêtes de longue durée dans PostgreSQL peuvent avoir plusieurs implications négatives pour votre base de données et votre application. Voici quelques raisons pour lesquelles les requêtes de longue durée sont généralement considérées comme indésirables :

• Impact sur les performances : Les requêtes de longue durée limitent les ressources de la base de données, y compris au niveau du CPU, de la mémoire et des E/S disque, pendant une période prolongée.

• Augmentation de la contention : Les requêtes de longue durée peuvent entraîner une contention accrue des ressources partagées, telles que les verrous et l’accès simultané aux objets de la base de données.

• Débit réduit : Lorsqu’une requête prend beaucoup de temps, cela peut limiter le nombre de requêtes pouvant être exécutées dans un délai donné.

• Mauvaise expérience utilisateur : Si votre application s’appuie sur une exécution rapide des requêtes, les requêtes de longue durée peuvent avoir un impact négatif sur l’expérience des utilisateurs. Les utilisateurs peuvent rencontrer des ralentissements ou un manque de réactivité, ce qui peut entraîner une frustration et une insatisfaction vis-à-vis de votre application.

• Épuisement des ressources : Les requêtes de longue durée peuvent consommer une quantité excessive de mémoire, ce qui entraîne une utilisation accrue de la mémoire et des erreurs potentielles de mémoire insuffisante. Elles peuvent également générer de gros fichiers temporaires sur le disque, causant potentiellement des problèmes d’espace disque.

Vacuum¶

Le panneau des informations comprend également des statistiques de nettoyage. Vous pouvez vérifier les noms des tables, le dernier nettoyage et le dernier nettoyage automatique. Vous pouvez également obtenir des informations sur le nombre de lignes obsolètes existantes, la date du dernier nettoyage des lignes obsolètes, et plus encore.

Les statistiques de nettoyage comprennent :

• Nom de la table

• Dernier nettoyage : dernière fois qu’une opération manuelle de nettoyage a été exécutée

• Dernier nettoyage automatique : dernière fois qu’un nettoyage automatique a été exécuté

• Nombre de lignes : nombre total de lignes pour la table

• Nombre de lignes obsolètes : nombre de lignes hors nettoyage/lignes obsolètes dans la table actuellement

• Facteur d’échelle : facteur d’échelle actuel défini dans les paramètres de nettoyage automatique

• Seuil : nombre total de lignes, en utilisant le facteur d’échelle, qui nécessiteraient une opération de nettoyage

• Nettoyage requis : si vous devez effectuer un nettoyage manuel sur la table

Tailles des tables¶

Les détails concernant les tailles de vos tables Postgres sont disponibles sous Tailles des tables dans les informations de l’instance. Cela affiche les informations sur la table, comme :

• noms de table

• nombre approximatif de lignes

• taille totale de la table

• taille des index de la table

• nombre d’octets de table dans les tables TOAST

• taille des lignes brutes de la table

Connexions¶

Les informations sur les connexions affichent toutes les connexions actuellement actives et inactives dans l’instance de la base de données. Les connexions actives se trouvent dans une session qui est actuellement connectée à la base de données et qui exécute une requête ou qui attendent d’en exécuter une.

Les connexions inactives sont courantes et ne sont pas problématiques en soi, mais elles peuvent le devenir en fonction de votre charge de travail et de votre configuration. Les connexions inactives consomment de la mémoire, de sorte qu’un grand nombre d’entre elles peuvent entraîner une utilisation excessive de la mémoire. Un nombre élevé de connexions inactives indique généralement que la base de données gagnerait à utiliser le regroupement de connexions.

Chaque session en cours d’exécution possède un pid qui est l’identifiant du processus, c’est-à-dire un identificateur unique attribué à chaque connexion de backend active.

Pour annuler une connexion, une requête ou un processus, mais laisser la session ouverte, utilisez cette instruction :

SELECT pg_cancel_backend(<pid>);

Une action plus radicale, qui fermera la connexion et annulera toute transaction, est la suivante :

SELECT pg_terminate_backend(<pid>);