En este documento se describe cómo generar manualmente informes de resumen del rendimiento, que le permiten comparar resúmenes de métricas del sistema entre dos momentos concretos. Puedes usar informes de estadísticas de rendimiento para identificar y mitigar los problemas de rendimiento de las bases de datos de AlloyDB para PostgreSQL. Las métricas del sistema que se registran en cada instantánea incluyen el uso de la CPU virtual (vCPU), el uso de la memoria, la E/S de disco, el recuento de transacciones y los eventos de espera.
Instantáneas automáticas y manuales
AlloyDB admite las siguientes copias de seguridad:
Capturas automáticas: de forma predeterminada, AlloyDB crea automáticamente capturas una vez al día y las almacena durante 7 días. Las capturas automáticas ayudan a generar informes con una granularidad de carga de trabajo diaria. No puedes cambiar la retención de una instantánea automática, pero sí puedes configurar la frecuencia.
Capturas manuales: puedes hacer capturas manualmente y generar informes.
Puedes combinar las capturas automáticas y manuales para generar informes de rendimiento. Por ejemplo, puedes generar un informe de resumen del rendimiento que compare una captura generada manualmente con una automática.
En este documento se describe cómo generar manualmente informes de resumen del rendimiento.
Cómo funcionan los informes de resumen de rendimiento
Los informes de resumen de rendimiento son una herramienta integrada de AlloyDB que recoge y analiza datos de rendimiento para ayudarte a identificar la causa de los problemas de rendimiento. Esta herramienta complementa otras funciones de observabilidad de AlloyDB, como Estadísticas del sistema, Estadísticas de consultas y el Explorador de métricas, que proporcionan métricas en tiempo real sobre tu instancia.
Los informes de resumen de rendimiento muestran métricas de la base de datos entre dos marcas de tiempo en un solo informe. Puedes usar la información del informe de resumen del rendimiento para identificar problemas de rendimiento con tu instancia de informe de resumen del rendimiento, como una disminución del rendimiento de la base de datos en determinados momentos del día o una disminución del rendimiento durante un periodo concreto.
Con el informe de resumen del rendimiento, puede comparar las métricas con un valor de referencia del rendimiento para obtener información valiosa sobre las métricas de rendimiento de la carga de trabajo, que puede usar para optimizar o solucionar problemas de rendimiento de la base de datos. Una línea de base es un conjunto personalizado de instantáneas de la base de datos que mide el rendimiento y el comportamiento estándar de una base de datos para una configuración y una carga de trabajo específicas.
Para obtener información sobre los eventos de espera en el informe de resumen de rendimiento, consulta la referencia del informe de resumen de rendimiento de la base de datos.
Roles obligatorios
Asegúrate de que tienes el rol alloydbsuperuser.
De forma predeterminada, AlloyDB asigna el rol pg_monitor a
alloydbsuperuser. Para obtener más información, consulta Roles predefinidos de PostgreSQL.
Si prefieres usar otros roles definidos por ti, ejecuta GRANT pg_monitor TO my_user como alloydbsuperuser primero. Para obtener más información, consulta Actualizar una cuenta de Gestión de Identidades y Accesos (IAM) con el rol adecuado.
Crear capturas
Las estadísticas de rendimiento son una herramienta muy útil para comprender y optimizar el rendimiento de tu base de datos. Recogen métricas clave del sistema en un momento concreto, lo que te permite comparar el rendimiento de tu base de datos entre dos momentos. AlloyDB admite dos tipos de instantáneas:
- Capturas de métricas del sistema: estas capturas registran métricas clave del sistema, como el uso de vCPU, el uso de memoria y las E/S de disco.
- Capturas de métricas del sistema y estadísticas de ejecución de SQL: estas capturas contienen todas las métricas del sistema de una captura estándar, además de estadísticas detalladas de ejecución de SQL de la extensión
pg_stat_statements.
De esta forma, puedes elegir el nivel de detalle que necesitas para tu análisis.
Crear una captura de métricas del sistema
Crea una captura al principio y al final de la carga de trabajo que te interese. El intervalo de tiempo entre las dos copias debe ser lo suficientemente largo como para captar una muestra representativa de la carga de trabajo.
Sigue estos pasos para optimizar el rendimiento de la base de datos de AlloyDB:
- Crea capturas de referencia cuando tu base de datos esté inactiva o cuando experimente una carga media.
- Conecta un cliente
psqla una instancia de AlloyDB. Ejecuta
SELECT perfsnap.snap(). El resultado es similar al siguiente:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)El resultado de este comando devuelve el ID de la captura (
snap_id), que en este ejemplo es1. Necesitará este ID para generar un informe de resumen del rendimiento más adelante. Es probable que elsnap_idde tu entorno sea diferente.Compara los informes que has creado con ambos conjuntos de estadísticas e identifica los cambios que podrían mejorar el rendimiento. Para obtener más información sobre las recomendaciones de rendimiento, consulta Recomendaciones para optimizar el rendimiento de las bases de datos.
Una vez que haya obtenido las métricas del informe de resumen de rendimiento, puede hacer otro conjunto de capturas y repetir el proceso.
Crear una instantánea que contenga estadísticas de ejecución de SQL
De forma predeterminada, AlloyDB usa la extensión pg_stat_statements para monitorizar las instrucciones SQL. Para incluir estadísticas detalladas de la ejecución de SQL en su informe de rendimiento, primero debe crear la extensión pg_stat_statements en su base de datos postgres. Ten en cuenta que la captura de estas estadísticas se habilita mediante la marca pg_stat_statements.track, no mediante la creación de la extensión en sí.
Para crear una instantánea que también contenga estadísticas de ejecución de SQL, siga estos pasos:
- Crea la extensión
pg_stat_statementsen la base de datospostgres.postgres=# CREATE EXTENSION pg_stat_statements;
- Ahora, cuando hagas una instantánea, se incluirán automáticamente las estadísticas de SQL de
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Ver una lista de las vistas generales
- Conecta un cliente
psqla una instancia de AlloyDB. - Ejecuta
SELECT * FROM perfsnap.g$snapshots. La salida tiene un aspecto similar al siguiente: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)
Generar un informe de resumen del rendimiento
Para generar un informe que muestre la diferencia entre dos copias de seguridad, por ejemplo, las copias de seguridad 1 y 2, ejecute el siguiente comando:SELECT perfsnap.report(1,2)
La segunda instantánea de una operación diferencial no tiene por qué seguir inmediatamente a la primera. Sin embargo, asegúrate de capturar la segunda instantánea en el diferencial después de la primera.
Ejemplo de informe
A continuación, se muestra un ejemplo abreviado de un informe de resumen del rendimiento generado:
Ejemplo de informe de resumen de rendimiento
$ 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)
Para obtener información sobre los campos de los informes y las recomendaciones de optimización del rendimiento, consulta Recomendaciones de optimización del rendimiento de la base de datos. Para obtener más información sobre los eventos de espera en los informes de resumen de rendimiento, consulta la referencia del informe de resumen de rendimiento de la base de datos.
Eliminar una instantánea
Para poder eliminar las copias de seguridad que forman parte de una línea de base, primero debes borrarla.
Para eliminar una instantánea, ejecuta el siguiente comando:
SELECT perfsnap.delete(SNAP_ID);
Sustituye SNAP_ID por el ID de la instantánea que quieras eliminar.
Una vez que elimines una instantánea, no podrás recuperarla.
Marcar una vista general como rendimiento de referencia
Para marcar todas las capturas con IDs entre 1 y 3, por ejemplo, como una referencia de rendimiento del sistema, ejecuta SELECT perfsnap.make_baseline(1, 3).
Borrar las métricas de rendimiento
Para borrar todas las líneas de base con IDs entre 1 y 3, por ejemplo, ejecuta
SELECT perfsnap.clear_baseline(1, 3).
Modificar la frecuencia de las instantáneas automáticas
Para personalizar la frecuencia de las capturas automáticas, define la marca perfsnap.interval, que establece el intervalo de las capturas automáticas en segundos. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.
Te recomendamos que definas el valor de la marca en varios minutos como mínimo para obtener información útil.
Para no desperdiciar recursos, cuando ya no necesites la frecuencia personalizada, restablece la marca al valor predeterminado (segundos por día).
Optimizar el rendimiento de la base de datos con los resultados del informe de resumen
Sigue estos pasos para optimizar el rendimiento de la base de datos de AlloyDB:
- Crea capturas de referencia cuando tu base de datos esté inactiva o cuando experimente una carga media.
- Inicia la carga de trabajo o la consulta cuyo rendimiento quieras mejorar.
- Cuando la carga de trabajo o la consulta alcancen el pico de uso de recursos, crea otro conjunto de instantáneas. Te recomendamos que uses el mismo intervalo en ambos informes.
- Compara los informes que has creado con ambos conjuntos de estadísticas e identifica los cambios que podrían mejorar el rendimiento. Para obtener más información sobre las recomendaciones de rendimiento, consulta Recomendaciones para optimizar el rendimiento de las bases de datos.
Recomendaciones para optimizar el rendimiento de la base de datos
En la siguiente tabla se enumeran las secciones del informe de resumen de rendimiento y las mejoras recomendadas para cada sección. Para obtener más información sobre las secciones del informe de resumen de rendimiento y los eventos de espera, consulta la referencia del informe de resumen de rendimiento de la base de datos.
| Sección | Campo de informe | Descripción del campo del informe | Recomendaciones de optimización |
|---|---|---|---|
| Detalles de la captura | Detalles de la captura | Proporciona el host, la versión compatible con PostgreSQL y la hora en la que la máquina está activa. | N/A |
| ID de captura | Muestra el ID y el momento de las copias de seguridad que se han usado para crear este informe. | N/A | |
| Información útil sobre el sistema | CPU del host | Detalles del uso de CPU del host. | Si la utilización de la CPU es superior al 80%, te recomendamos que aumentes la escala a la siguiente talla disponible. |
| Memoria del host | Detalles del uso de la memoria del host. | Si la memoria libre es inferior al 15%, le recomendamos que aumente el tamaño al siguiente disponible. | |
| Cargar perfil | Enumera los contadores que ayudan a determinar la carga de trabajo de registro anticipado (WAL) generada, los requisitos de E/S y la gestión de conexiones. | Si las lecturas físicas son superiores a las lógicas, considera la posibilidad de aumentar el tamaño al siguiente disponible para admitir un almacenamiento en caché de datos más grande. | |
| Desglose del tiempo de respuesta y de la clase de espera | Desglose del tiempo que han dedicado los procesos de Postgres durante la ejecución de la carga de trabajo. | Por ejemplo, céntrate en reducir el tiempo de espera de las operaciones de E/S si los procesos están principalmente en estado de espera. | |
| Información sobre la carga de trabajo de la base de datos | Información de la carga de trabajo por base de datos | Métricas clave de cada base de datos, como las confirmaciones, las reversiones, la tasa de aciertos e información sobre las tablas temporales y las operaciones de ordenación. | Si el número de rollbacks es elevado, te recomendamos que diagnostiques tu aplicación. |
| Información de DML y DQL por base de datos | Contadores de operaciones de consulta. | Clasifica tu carga de trabajo como de lectura o de escritura. | |
| Información sobre conflictos de bases de datos | Contadores de problemas habituales de aplicaciones y bases de datos. | Localiza problemas en tu aplicación si hay un interbloqueo. | |
| Información sobre el tamaño de la base de datos | Muestra cuánto ha crecido la base de datos durante el intervalo entre dos copias. Este campo también muestra si la base de datos tiene límites de conexión establecidos. | Localiza los problemas de tu aplicación si el crecimiento de la base de datos es demasiado grande. | |
| Información sobre aspiradoras | Información sobre aspiradoras | Detalles de las operaciones de E/S y los contadores de las operaciones de vacío. | De forma predeterminada, AlloyDB realiza un proceso de limpieza adaptativo. Puedes anular algunos de los ajustes de vacío para adaptarlos a tu carga de trabajo. Por ejemplo, reduce las operaciones de vacío si se dedica demasiada E/S a estas solicitudes. |
| Información de VACUUM por base de datos | Muestra la siguiente información:
|
Si la antigüedad del campo XID inactivo es demasiado alta o si el porcentaje de transacciones consumidas se acerca al 90%, considera la posibilidad de realizar un vacío. Si el espacio de vacío agregado disminuye, significa que Postgres aplicará un vacío para evitar que se produzca un envolvente. | |
| Detalles de espera de procesos de base de datos | Información detallada sobre los procesos en segundo plano y del backend | Detalles de todas las esperas de los procesos de backend y en segundo plano en el intervalo del informe. La información incluye el tiempo de espera acumulado, el tiempo de CPU y el tiempo medio por tipo de espera. | Para reducir el tiempo de espera de WALWrite, por ejemplo, aumenta el número de wal_buffers disponibles para la base de datos. |
| Histograma detallado de eventos de espera de backend y en segundo plano | Se incluye de forma predeterminada en el informe de resumen de rendimiento. La lista contiene el histograma de eventos de espera de los procesos de backend y en segundo plano, que se dividen en 32 segmentos, desde 1 µs hasta más de 16 segundos. | Localiza los eventos de espera y determina si hay demasiados en el intervalo de tiempo de espera más amplio. Puede que haya un problema con demasiados eventos de espera o con cada tiempo de espera consumido. | |
| Estadísticas varias | Estadísticas del registro de escritura anticipada (WAL) | Resumen de las estadísticas de WAL. | Si el tiempo de sincronización es demasiado largo, ajusta las marcas de la base de datos relacionada (GUC) para mejorar tu carga de trabajo. GUC es el subsistema de PostgreSQL que gestiona la configuración del servidor. |
| Estadísticas de resumen (de todas las bases de datos) | Resumen de todas las operaciones de la base de datos que se producen durante el intervalo de la instantánea. | N/A | |
| Ajustes de los parámetros | Ajustes de los parámetros | Parámetros de configuración de Postgres clave en el momento de la última instantánea. | Comprueba la configuración del parámetro GUC (las marcas de la base de datos de Postgres) para determinar si los valores no son los esperados o no son los recomendados. |
| Estadísticas de ejecución de SQL | Información por consulta (las 50 principales) por tiempo total transcurrido | Lista las 50 consultas principales que han consumido más tiempo durante las dos instantáneas, así como el número total de ejecuciones, desglosado por el usuario y la base de datos en los que se ha emitido la consulta.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
Usa esta sección para identificar la consulta más pesada, que es la que ocupa la mayor parte del tiempo del sistema. |
| Información por consulta (las 50 principales) por IO de lectura | Muestra las 50 consultas principales que han dedicado más tiempo de E/S de lectura durante las dos instantáneas, así como su número de ejecuciones, aciertos de búfer y lecturas de bloques, tanto en total como de media.ReadIO = blk_read_time + temp_blk_read_time acumulado durante las dos instantáneasBuffer Hits = shared_blks_hit + local_blks_hit acumulado durante las dos instantáneasBuffer Reads = shared_blks_read + local_blks_read acumulado durante las dos instantáneasAlloyDB Cloud hace un seguimiento de estos campos de forma predeterminada, ya que track_io_timing está definido. |
Usa esta sección para identificar las consultas que requieren muchas operaciones de E/S, sobre todo si necesitan leer datos de los discos con frecuencia. | |
| Información por consulta (las 50 principales) por desviación estándar del tiempo transcurrido | Lista las 50 consultas principales que tienen la desviación estándar más alta del tiempo transcurrido, mostrando las desviaciones estándar calculadas en el momento de la primera y la última instantánea. Aquí, el valor hace referencia a stddev_exec_time de pg_stat_statements. |
Si la desviación estándar de una consulta es alta, significa que el tiempo de ejecución de la consulta varía mucho y que puede que sea el momento de analizar la E/S. |
Limitaciones
Para evitar que el espacio se infle debido a un consumo excesivo de almacenamiento, puedes crear manualmente un máximo de 2500 copias de un mismo instante en una instancia.
Si el número de copias supera el límite, AlloyDB elimina todas las copias manuales que tengan más de 90 días. Para no superar el límite de las copias de seguridad, debes eliminar las copias de seguridad innecesarias antes de crear una nueva.
AlloyDB limpia periódicamente las copias de seguridad manuales que tienen más de 90 días.
Siguientes pasos
- Consulte información sobre los eventos de espera en los informes de resumen de rendimiento.