Fonctionnement des rapports instantanés sur les performances
Les rapports instantanés sur les performances sont un outil AlloyDB Omni intégré qui capture et analyse les données de performances pour vous aider à identifier la cause des problèmes de performances.
Les rapports instantanés sur les performances affichent les métriques de base de données entre deux codes temporels dans un seul rapport. Vous pouvez utiliser les informations du rapport sur l'instantané des performances pour identifier les problèmes de performances de votre instance de rapport sur l'instantané des performances, comme une baisse des performances de la base de données à certaines heures de la journée ou une baisse des performances sur une période donnée.
Le rapport sur l'instantané des performances vous permet de comparer les métriques à un benchmark de performances pour obtenir des insights sur les métriques de performances des charges de travail. Vous pouvez les utiliser pour optimiser les performances de la base de données ou résoudre les problèmes associés. Une référence est un ensemble personnalisé d'instantanés de base de données qui mesurent les performances et le comportement standards d'une base de données pour une configuration et une charge de travail spécifiques.
Pour en savoir plus sur les événements d'attente dans le rapport sur l'instantané des performances, consultez la documentation de référence sur le rapport sur l'instantané des performances de la base de données.
Rôles requis
Assurez-vous de disposer du rôle pg_monitor.
Ce rôle est accordé aux super-utilisateurs, qui peuvent ensuite accorder pg_monitor à d'autres utilisateurs.
Par exemple, postgres est le super-utilisateur par défaut. Vous pouvez exécuter GRANT pg_monitor TO my_user en tant que postgres pour permettre à my_user d'utiliser l'outil d'instantané des performances, comme décrit dans ce document.
Installer le rapport "Instantané des performances"
perfsnap est le nom du schéma contenant les fonctions SQL qui permettent aux utilisateurs de capturer des instantanés ou de générer des rapports. Ce schéma fait partie de l'extension g_stats AlloyDB Omni. Utilisez le rôle de super-utilisateur pour installer le rapport "Instantané des performances".
Pour utiliser les API perfsnap, connectez-vous à n'importe quelle base de données dans laquelle les utilisateurs souhaitent installer l'extension, puis créez l'extension g_stats à l'aide de la commande suivante :
CREATE EXTENSION IF NOT EXISTS g_stats;
Créer un instantané des métriques système
Créez un instantané au début et à la fin de la charge de travail qui vous intéresse. L'intervalle de temps entre les deux instantanés laisse suffisamment de temps à la charge de travail pour progresser, de sorte que le système puisse accumuler des métriques qui reflètent la charge de travail. Une fois que vous avez obtenu les métriques du rapport d'instantané des performances, vous pouvez prendre un autre ensemble d'instantanés et répéter le processus.
- Connectez un client
psqlà une instance AlloyDB. Exécutez
SELECT perfsnap.snap(). La sortie ressemble à ceci :postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Afficher la liste des instantanés
- Connectez un client
psqlà une instance AlloyDB. Exécutez
SELECT * FROM perfsnap.g$snapshots. La sortie ressemble à ceci :postgres=# select * from perfsnap.g$snapshots; snap_id | snap_time | instance_id | node_id | snap_description | snap_type | is_baseline ---------+-------------------------------+-------------+---------+--------------------+-----------+------------- 1 | 2023-11-13 22:13:43.159237+00 | sr-primary | | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | sr-primary | | Automatic snapshot | Automatic | f (2 rows)
Générer un rapport instantané
Pour générer un rapport qui capture la différence entre les instantanés 1 et 2, par exemple, exécutez SELECT perfsnap.report(1,2).
Le deuxième instantané d'une opération différentielle ne doit pas nécessairement suivre immédiatement le premier instantané. Toutefois, assurez-vous de capturer le deuxième instantané dans le différentiel après le premier instantané.
Le rapport instantané sur les performances généré ressemble à l'exemple abrégé suivant :
Exemple de rapport instantané sur les performances
$ psql -d postgres -U alloydbsuperuser
postgres=> select perfsnap.report(22, 23);
report
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PGSNAP DB Report for:
Snapshot details
--------------------------------------
Host i841-sr-primary-2a34f46e-06bc
Release 14.12
Startup Time 2024-10-08 03:23:15+00
Snap Id Snap Time
------------ ---------- ------------------------
Begin Snap: 22 24.10.2024 04:33:56 (UTC) Automatic snapshot
End Snap: 23 25.10.2024 04:38:56 (UTC) Automatic snapshot
Elapsed: 1 day 00:04:59.979321
Database Cache sizes
~~~~~~~~~~~~~
Shared Buffers: 31 GB Block Size: 8192
Effective Cache Size: 25 GB WAL Buffers: 16384
Host CPU
~~~~~~~~~~
%User %Nice %System %Idle %WIO %IRQ %SIRQ %Steal %Guest
------- ------- ------- ------- ------- ------- ------- ------- -------
1.07 0.22 0.91 97.40 0.09 0.00 0.31 0.00 0.00
Host Memory
~~~~~~~~~~~~
Total Memory: 63 GB
Available Memory: 11 GB
Free Memory: 726 MB
Buffers Memory: 3706 MB
Load profile (in bytes)
~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
------------ ---------------
Redo size: 63083.64 4489.93
Logical reads: 1961.21 139.59
...
Response Time Profile (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPU time: 5399 ( 0.39%)
Wait time: 1386906 ( 99.61%)
Total time: 1392306
Backend Processes Wait Class Breakdown (in s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IO 119.300 ( 98.91%)
LWLock 1.305 ( 1.08%)
IPC .010 ( 0.01%)
Lock .000 ( 0.00%)
Backend Processes Wait Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits Time (us) Avg (us)
-------------------------------------- ------------- ------------- -------------- -------------
CPU 1995948632
WALInsert LWLock 1 6656 6656
Vacuum Information
~~~~~~~~~~~~~~~~~~~
Num Analyze operations: 1976
Num Vacuum operations: 3435
Per Database Information
~~~~~~~~~~~~~~~~~~~~~~~~~
Name Commits Rollbacks BlkRds Blkhits TempFiles TempBytes
------------------------- ------------- ------------- ------------- ------------- ------------- -------------
bench 27939 0 0 7823038 0 0 bytes
postgres 39792 0 7 11089243 0 0 bytes
Per Database DML & DQL Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Tuples returned Tuples fetched Tuples inserted Tuples updated Tuples deleted Index splits Index Only heap fetches HOT updates
------------------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ------------------------- ----------------
bench 16119481 4843262 0 0 0 0 16 0
postgres 25415473 6327188 0 10 0 0 0 8
Per Database Conflict Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Lock Timeout Old Snapshot Buffer Pins Deadlock
------------------------- ------------- ------------- ------------- -------------
bench 0 0 0 0
postgres 0 0 0 0
Per Database Vacuum Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Frozen XID % Consumed Aggregate Vacuum Gap
------------------------- ------------- ------------- --------------------
bench 179460916 9.00% 20539084
postgres 179339239 9.00% 20660761
Per Database Sizing Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Conn.
Name Collation Limit Tablespace DB Size Growth
-------------------- ------------- ------- -------------------- ---------- ----------
bench C.UTF-8 -1 pg_default 80 GB 0 bytes
postgres C.UTF-8 -1 pg_default 135 MB 0 bytes
Backend Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 1 0 0 0 0 0 0 0 0 0 0
Background Wait Event Histogram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Class Waits <= 1us <= 2us <= 4us <= 8us <= 16us <= 32us <= 64us <= 128us <= 256us <= 512us
-------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
WALInsert LWLock 542 107 174 39 113 93 8 1 1 0 1
Write Ahead Log (WAL) Statistics
--------------------------------
Records Full Page Images Bytes Buffers Full Write Sync Write Time Sync Time
----------- ---------------- ----------- ------------ ----------- ----------- ----------- -----------
2936305 100 805989345 0 0 0 0 0
Summary Stats (across all databases)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name Value
-------------------------------- ----------------------------------
Buffers evicted 0
Commits 1216693
...
Parameter Settings
~~~~~~~~~~~~~~~~~~~
Parameter Value
--------------------------------- --------------------------------------------------------------
DateStyle ISO, MDY
TimeZone UTC
autovacuum on
work_mem 4096
Columnar Engine available size Columnar Engine configured size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14959MB 19293MB
Columnar Engine Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name count
---------------------------------------------------------- ------------
CU Populations/Refreshes 13197
CU Auto Refreshes 10975
...
Columnar Engine Ultra-fast Cache Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ultra-fast Cache Size (MB): 19200
Ultra-fast Cache Used Size (MB): 0
Ultra-fast Cache Block Size (MB): 80
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(xxx rows)
Pour en savoir plus sur les champs de rapport et les recommandations d'optimisation des performances, consultez Recommandations d'optimisation des performances des bases de données. Pour en savoir plus sur les événements d'attente dans les rapports d'instantané des performances, consultez Référence du rapport d'instantané des performances de la base de données.
Supprimer un instantané
Avant de pouvoir supprimer des instantanés qui font partie d'une référence existante, vous devez effacer la référence .
Pour supprimer un instantané, exécutez SELECT perfsnap.delete(n). Une fois un instantané supprimé, vous ne pouvez pas le récupérer.
Marquer un instantané comme référence de performances
Pour marquer tous les instantanés dont l'ID est compris entre 1 et 3, par exemple, comme référence des performances du système, exécutez SELECT perfsnap.make_baseline(1, 3).
Des performances de référence claires
Pour effacer toutes les références avec des ID compris entre 1 et 3, par exemple, exécutez SELECT perfsnap.clear_baseline(1, 3).
Optimiser les performances de la base de données à l'aide des résultats du rapport instantané
Pour optimiser les performances de la base de données AlloyDB, procédez comme suit :
- Créez des instantanés de référence lorsque votre base de données est inactive ou lorsqu'elle connaît une charge moyenne.
- Démarrez la charge de travail ou la requête dont vous souhaitez améliorer les performances.
- Lorsque la charge de travail ou la requête atteint son pic d'utilisation des ressources, créez un autre ensemble d'instantanés. Nous vous recommandons d'utiliser le même intervalle pour les deux rapports.
- Comparez les rapports que vous avez créés avec les deux ensembles d'instantanés et identifiez les modifications susceptibles d'améliorer les performances. Pour en savoir plus sur les recommandations de performances, consultez Recommandations pour optimiser les performances des bases de données.
Recommandations d'optimisation des performances de la base de données
Le tableau suivant liste les sections du rapport instantané sur les performances et les améliorations recommandées pour chacune d'elles. Pour en savoir plus sur les sections du rapport d'instantané des performances et sur les événements d'attente, consultez Référence du rapport d'instantané des performances de la base de données.
| Section | Champ du rapport | Description des champs du rapport | Recommandations d'optimisation |
|---|---|---|---|
| Détails de l'instantané | Détails de l'instantané | Fournit l'hôte, la version compatible avec PostgreSQL et l'heure à laquelle la machine est opérationnelle. | N/A |
| ID de l'instantané | Liste l'ID et le point dans le temps des instantanés utilisés pour créer ce rapport. | N/A | |
| Insights sur le système | Processeur hôte | Détails sur l'utilisation du processeur hôte. | Si l'utilisation du processeur est supérieure à 80 %, nous vous recommandons de passer à un système comportant davantage de processeurs virtuels. |
| Mémoire de l'hôte | Détails de l'utilisation de la mémoire hôte. | Si la mémoire libre est inférieure à 15 %, nous vous recommandons de passer à la taille disponible suivante. | |
| Charger le profil | Liste les compteurs qui aident à caractériser votre charge de travail en termes de journalisation Write-Ahead (WAL), d'exigences d'E/S et de gestion des connexions. | Si les lectures physiques sont supérieures aux lectures logiques, envisagez de passer à la taille supérieure disponible pour prendre en charge une mise en cache plus importante des données. | |
| Répartition du temps de réponse et de la classe d'attente | Répartition du temps passé par les processus Postgres lors de l'exécution de la charge de travail. | Par exemple, si les processus sont principalement en état d'attente, concentrez votre optimisation sur la réduction de l'attente d'E/S. | |
| Informations sur la charge de travail de la base de données | Informations sur la charge de travail par base de données | Métriques clés pour chaque base de données, y compris les commits, les rollbacks, le taux de réussite et des informations sur les tables temporaires et les opérations de tri. | Si le nombre de rétrocessions est élevé, envisagez de diagnostiquer votre application. |
| Informations sur le LMD et le LQD par base de données | Compteurs pour les opérations de requête. | Déterminez si votre charge de travail est axée sur la lecture ou l'écriture. | |
| Informations sur les conflits de base de données | Compteurs pour les problèmes courants liés aux applications et aux bases de données. | Localisez les problèmes dans votre application en cas d'impasse. | |
| Informations sur le dimensionnement de la base de données |
Indique la croissance de la base de données au cours de l'intervalle entre deux instantanés. Ce champ indique également si des limites de connexion ont été établies pour la base de données. | Identifiez les problèmes dans votre application si la croissance de la base de données est trop importante. | |
| Informations sur l'aspirateur | Informations sur l'aspirateur | Détails des E/S et des compteurs pour les opérations de vidage. | Par défaut, AlloyDB effectue un nettoyage adaptatif. Vous pouvez remplacer certains paramètres de vacuum pour les adapter à votre charge de travail. Par exemple, réduisez les opérations de nettoyage si trop d'E/S sont consacrées à ces requêtes. |
| Informations sur le vide par base de données | Affiche les informations suivantes :
|
Si l'âge du champ "Frozen XID" est trop ancien ou si le pourcentage de transactions consommées est proche de 90 %, envisagez d'effectuer un nettoyage. Si l'écart de vide global diminue, cela indique qu'un vide sera appliqué par Postgres pour éviter le retour à la ligne. | |
| Détails de l'attente des processus de base de données | Informations détaillées sur les processus d'arrière-plan et de backend |
Détails de toutes les attentes par processus de backend et d'arrière-plan dans l'intervalle du rapport. Les informations incluent le temps d'attente cumulé, le temps CPU et le temps moyen par type d'attente. | Pour réduire l'attente sur WALWrite, par exemple, augmentez le nombre de wal_buffers disponibles pour la base de données. |
| Histogramme détaillé des événements d'attente de backend et d'arrière-plan | Elle est incluse par défaut dans le rapport "Instantané des performances". La liste contient l'histogramme des événements d'attente pour les processus de backend et d'arrière-plan, qui sont divisés en 32 buckets, de 1 µs à plus de 16 s. | Localisez les événements d'attente et déterminez s'il y en a trop dans le bucket de temps d'attente le plus long. Il peut y avoir un problème lié à un nombre trop important d'événements d'attente ou à chaque durée d'attente consommée. | |
| Statistiques diverses | Statistiques des journaux de transaction (WAL) | Récapitulatif des statistiques WAL. | Si la synchronisation prend trop de temps, ajustez les indicateurs de base de données associés (GUC) pour améliorer votre charge de travail. GUC est le sous-système PostgreSQL qui gère la configuration du serveur. |
| Statistiques récapitulatives (pour toutes les bases de données) | Récapitulatif de toutes les opérations de base de données qui se produisent pendant l'intervalle de l'instantané. | N/A | |
| Détails du paramètre | Détails du paramètre | Paramètres de configuration Postgres clés à l'heure de l'instantané de fin. | Vérifiez les paramètres GUC (indicateurs de la base de données Postgres) pour déterminer si les valeurs ne sont pas celles attendues ou ne sont pas recommandées. |
Limites
Pour éviter le gonflement de l'espace, vous pouvez créer manuellement jusqu'à 2 500 instantanés sur une instance. Le gonflement de l'espace garantit que les instantanés n'occupent pas trop d'espace de stockage dans votre base de données.
Si le nombre d'instantanés dépasse la limite, AlloyDB Omni supprime tous les instantanés manuels datant de plus de 90 jours. Pour ne pas dépasser la limite d'instantanés, vous devez supprimer les instantanés inutiles avant d'en créer un.
AlloyDB Omni supprime régulièrement les instantanés manuels datant de plus de 90 jours.
Étapes suivantes
- En savoir plus sur les événements d'attente dans les rapports sur les instantanés des performances