Ce document explique comment générer manuellement des rapports sur les instantanés des performances. Ils vous permettent de comparer des instantanés de métriques système entre deux points temporels. Vous pouvez utiliser les rapports sur les instantanés des performances pour identifier et résoudre les problèmes de performances des bases de données AlloyDB pour PostgreSQL. Les métriques système capturées dans chaque instantané incluent l'utilisation du processeur virtuel (vCPU), l'utilisation de la mémoire, les E/S disque, le nombre de transactions et les événements d'attente.
Instantanés automatiques et manuels
AlloyDB est compatible avec les instantanés suivants :
Instantanés automatiques : par défaut, AlloyDB capture automatiquement des instantanés une fois par jour et les stocke pendant sept jours. Les instantanés automatiques permettent de générer des rapports avec une granularité de charge de travail quotidienne. Vous ne pouvez pas modifier la durée de conservation d'un instantané automatique, mais vous pouvez configurer la fréquence.
Instantanés manuels : vous pouvez capturer des instantanés et générer des rapports manuellement.
Vous pouvez combiner des instantanés automatiques et manuels pour générer des rapports sur les performances. Par exemple, vous pouvez générer un rapport instantané sur les performances qui compare un instantané généré manuellement à un instantané automatique.
Ce document explique comment générer manuellement des rapports "Performance Snapshot".
Fonctionnement de Performance Snapshot Reports
Performance Snapshot Reports est un outil AlloyDB intégré qui capture et analyse les données sur les performances pour vous aider à identifier la cause des problèmes de performances. Cet outil complète les autres fonctionnalités d'observabilité d'AlloyDB, comme les insights système, les insights sur les requêtes et l'explorateur de métriques, qui fournissent des métriques en temps réel sur votre instance.
Performance Snapshot Reports affiche les métriques de base de données entre deux codes temporels dans un seul rapport. Vous pouvez utiliser Performance Snapshot Reports pour identifier les problèmes de performances de votre instance Performance Snapshot Reports, 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.
Performance Snapshot Reports vous permet de comparer les métriques à une référence en termes de performances afin d'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 Performance Snapshot Reports, consultez la documentation de référence sur Performance Snapshot Reports pour les bases de données.
Rôles requis
Assurez-vous de disposer du rôle alloydbsuperuser.
Par défaut, AlloyDB attribue le rôle pg_monitor à alloydbsuperuser. Pour en savoir plus, consultez la section Rôles prédéfinis PostgreSQL.
Si vous préférez utiliser vos autres rôles définis, exécutez d'abord GRANT pg_monitor TO my_user en tant que alloydbsuperuser. Pour en savoir plus, consultez Mettre à jour un compte Identity and Access Management (IAM) avec le rôle approprié.
Créer des instantanés
Les instantanés de performances sont un outil puissant pour comprendre et optimiser les performances de votre base de données. Ils capturent les métriques système clés à un moment précis, ce qui vous permet de comparer les performances de votre base de données entre deux points dans le temps. AlloyDB est compatible avec deux types d'instantanés :
- Instantanés des métriques système : ces instantanés capturent les métriques système clés telles que l'utilisation du processeur virtuel, de la mémoire et des E/S disque.
- Instantanés des métriques système et des statistiques d'exécution SQL : ces instantanés contiennent toutes les métriques système d'un instantané standard, ainsi que des statistiques d'exécution SQL détaillées provenant de l'extension
pg_stat_statements.
Vous pouvez ainsi choisir le niveau de détail dont vous avez besoin pour votre analyse.
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 doit être suffisamment long pour capturer un échantillon représentatif de la charge de travail.
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 est soumise à une charge moyenne.
- Connectez un client
psqlà une instance AlloyDB. Exécutez
SELECT perfsnap.snap(). La sortie ressemble à ceci :postgres=# select perfsnap.snap(); snap ------ 1 (1 row)Le résultat de cette commande renvoie l'ID du snapshot (
snap_id), qui est1dans cet exemple. Vous aurez besoin de cet ID pour générer un rapport instantané sur les performances ultérieurement. Lesnap_iddans votre propre environnement est probablement différent.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 d'optimisation des performances de la base de données.
Une fois que vous avez obtenu les métriques de Performance Snapshot Reports, vous pouvez prendre un autre ensemble d'instantanés et répéter le processus.
Créer un instantané contenant des statistiques d'exécution SQL
Par défaut, AlloyDB utilise l'extension pg_stat_statements pour suivre les instructions SQL. Pour inclure des statistiques d'exécution SQL détaillées dans votre rapport sur les performances, vous devez d'abord créer l'extension pg_stat_statements dans votre base de données postgres. Notez que la capture de ces statistiques est activée par l'indicateur pg_stat_statements.track, et non par la création de l'extension elle-même.
Pour créer un instantané contenant également des statistiques d'exécution SQL, procédez comme suit :
- Créez l'extension
pg_stat_statementsdans la base de donnéespostgres.postgres=# CREATE EXTENSION pg_stat_statements;
- Désormais, lorsque vous prenez un instantané, il inclut automatiquement les statistiques SQL de
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (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 Performance Snapshot Reports
Pour générer un rapport qui capture la différence entre deux instantanés (par exemple, les instantanés 1 et 2), exécutez la commande suivante :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é.
Exemple de rapport
Voici un exemple abrégé de rapport instantané sur les performances généré :
Exemple de rapport Performance Snapshot Reports
$ 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
SQL Report
~~~~~~~~~~
NOTE: Query might be empty if query ID does not have a match in pg_stat_statements at report time. This is expected if the query is not run recently.
Per Query Information (Top 50) By Total Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total Elapsed Time(ms) Execution Count Avg Elapsed Time(ms)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 276400877.8014 36928106 7.4848
prepare payment (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, NUMERIC, VARCHAR) AS select p 36272 36274 tpcc 3864683359055073968 127719636.4656 36928456 3.4586
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 48540963.0880 3694128 13.1400
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 35361366.9271 3692785 9.5758
...
Per Query Information (Top 50) By Read IO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Total ReadIO Time(ms) Execution Count Avg ReadIO Time(ms) Total buffer hits Avg buffer hits Total blk reads Avg blk reads
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
prepare ostat (INTEGER, INTEGER, INTEGER, INTEGER, VARCHAR) AS select * from ostat($1,$2,$3,$4,$5) a 36272 36274 tpcc -1640504351418263816 498072.4004 3693895 0.1348 80360201 21.75486877672484 105858 0.028657555236410347
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 12.5438 3694128 0.0000 4477308168 1212.0067761593534 1219908 0.33022894712906536
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 0.8039 36928106 0.0000 10337394097 279.9329620912592 6245570 0.16912781825312134
SELECT name, default_version, installed_version FROM pg_catalog.pg_available_extensions 10 5 postgres 6619165036968781114 0.0000 361 0.0000 361 1 0 0
...
Per Query Information (Top 50) By Standard Deviation of Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query Text UserID DBID DBName QueryID Begin STDDEV Elapsed Time(ms) End STDDEV Elapsed Time(ms)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT COUNT($1) FROM perfsnap.g$snapshots 10 5 postgres -8741741796612173369 17.8084 18.1239
prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2) 36272 36274 tpcc 2323704420019807054 15.0626 19.8495
prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6) 36272 36274 tpcc -5467151541922966497 13.9820 17.0074
prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3) 36272 36274 tpcc -8637448842172635004 8.4333 9.6205
----------------------------------------------------
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 pour optimiser les performances des bases de données. Pour en savoir plus sur les événements d'attente dans Performance Snapshot Report, consultez la documentation de référence Performance Snapshot Report pour les bases 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 la commande suivante :
SELECT perfsnap.delete(SNAP_ID);
Remplacez SNAP_ID par l'ID de l'instantané que vous souhaitez supprimer.
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).
Effacer les performances de référence
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).
Modifier la fréquence des instantanés automatiques
Pour personnaliser la fréquence des instantanés automatiques, définissez l'indicateur perfsnap.interval, qui définit l'intervalle des instantanés automatiques en secondes. Pour en savoir plus, consultez Configurer des options de base de données.
Nous vous recommandons de définir la valeur de l'indicateur sur au moins plusieurs minutes pour capturer des informations pertinentes.
Pour éviter de gaspiller des ressources, lorsque vous n'avez plus besoin de la fréquence personnalisée, réinitialisez l'indicateur sur la valeur par défaut (qui est "secondes par jour").
Optimiser les performances de la base de données à l'aide des résultats du rapport sur les instantanés
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 est soumise à 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 d'optimisation des performances de la base de données.
Recommandations d'optimisation des performances de la base de données
Le tableau suivant liste les sections du rapport Performance Snapshot Report et les améliorations recommandées pour chacune d'elles. Pour en savoir plus sur les sections du rapport Performance Snapshot Report de la base de données et sur les événements d'attente, consultez la documentation de référence sur Performance Snapshot Report pour 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 à la taille disponible suivante. |
| Mémoire de l'hôte | Détails sur l'utilisation de la mémoire de l'hôte. | Si la mémoire libre est inférieure à 15 %, nous vous recommandons de passer à la taille disponible suivante. | |
| Chargement du profil | Liste les compteurs qui aident à qualifier votre charge de travail en termes de journalisation 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 rollbacks est élevé, envisagez d'effectuer un diagnostic sur 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'interblocage. | |
| 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 le nettoyage | Informations sur le nettoyage | Détails des E/S et des compteurs pour les opérations de nettoyage. | Par défaut, AlloyDB effectue un nettoyage adaptatif. Vous pouvez remplacer certains paramètres de nettoyage 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 "XID figés" est trop ancien ou si le pourcentage de transactions consommées est proche de 90 %, envisagez d'effectuer un nettoyage. Si l'écart de nettoyage global diminue, cela indique qu'un nettoyage 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 de backend et d'arrière-plan | 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 | Il est inclus 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 grand. Il peut y avoir un problème lié à un nombre trop important d'événements d'attente ou à la durée d'attente consommée. | |
| Statistiques diverses | Statistiques des journaux 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 (toutes les bases de données confondues) | 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 au moment 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. |
| Statistiques d'exécution SQL | Informations par requête (50 premières) par temps total écoulé | Liste les 50 requêtes qui ont passé le plus de temps écoulé entre les deux instantanés, ainsi que leur nombre total d'exécutions, ventilé par utilisateur et par base de données où la requête est émise.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
Utilisez cette section pour identifier la requête la plus lourde qui prend le plus de temps système. |
| Informations par requête (50 premières) par E/S en lecture | Liste les 50 requêtes les plus gourmandes en temps d'E/S de lecture entre les deux instantanés, ainsi que leur nombre d'exécutions, leurs accès au cache, leurs lectures de blocs, à la fois au total et en moyenne.ReadIO = blk_read_time + temp_blk_read_time cumulé entre les deux instantanésBuffer Hits = shared_blks_hit + local_blks_hit cumulé entre les deux instantanésBuffer Reads = shared_blks_read + local_blks_read cumulé entre les deux instantanésCes champs sont suivis par AlloyDB Cloud par défaut, car track_io_timing est défini. |
Utilisez cette section pour identifier les requêtes gourmandes en E/S, en particulier si elles doivent lire fréquemment des données sur les disques. | |
| Informations par requête (50 premières) par écart-type du temps écoulé | Liste des 50 requêtes dont l'écart type du temps écoulé est le plus élevé, avec les écarts types calculés au début et à la fin de l'instantané. Ici, la valeur fait référence à stddev_exec_time à partir de pg_stat_statements. |
Pour une requête avec un écart-type élevé, cela signifie que le temps d'exécution de la requête varie beaucoup. Il est peut-être temps de regarder les E/S. |
Limites
Pour éviter la surcharge de l'espace due à une consommation excessive de stockage, vous pouvez créer manuellement jusqu'à 2 500 instantanés sur une instance.
Si le nombre d'instantanés dépasse la limite, AlloyDB 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 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 Performance Snapshot Report