Este documento descreve como gerar manualmente relatórios de resumo do desempenho, que lhe permitem comparar resumos de métricas do sistema entre dois momentos. Pode usar relatórios de instantâneos de desempenho para identificar e mitigar problemas de desempenho da base de dados do AlloyDB for PostgreSQL. As métricas do sistema captadas em cada captura de ecrã incluem a utilização da CPU virtual (vCPU), a utilização da memória, a E/S do disco, a quantidade de transações e os eventos de espera.
Capturas de ecrã automáticas e manuais
O AlloyDB suporta as seguintes cópias instantâneas:
Instantâneos automáticos: por predefinição, o AlloyDB captura automaticamente instantâneos uma vez por dia e armazena-os durante 7 dias. As capturas de ecrã automáticas ajudam a gerar relatórios com granularidade da carga de trabalho diária. Não pode alterar a retenção de uma captura de ecrã automática, mas pode configurar a frequência.
Instantâneos manuais: pode capturar instantâneos manualmente e gerar relatórios.
Pode combinar resumos automáticos e manuais para gerar relatórios de desempenho. Por exemplo, pode gerar um relatório de instantâneo de desempenho que compare um instantâneo gerado manualmente com um instantâneo automático.
Este documento descreve como gerar manualmente relatórios de resumo de desempenho.
Como funcionam os relatórios de resumo de desempenho
Os relatórios de resumo de desempenho são uma ferramenta integrada do AlloyDB que captura e analisa dados de desempenho para ajudar a identificar a causa dos problemas de desempenho. Esta ferramenta complementa outras funcionalidades de observabilidade do AlloyDB, como as estatísticas de sistemas, as estatísticas de consultas e o explorador de métricas>, que fornecem métricas em tempo real sobre a sua instância.
Os relatórios de resumo de desempenho apresentam métricas da base de dados entre duas datas/horas num único relatório. Pode usar as informações do relatório de resumo do desempenho para identificar problemas de desempenho com a instância do relatório de resumo do desempenho, como o desempenho reduzido da base de dados durante determinadas horas do dia ou o desempenho reduzido durante um determinado período.
Com o relatório de resumo de desempenho, compara as métricas com uma base de referência de desempenho para obter estatísticas sobre as métricas de desempenho da carga de trabalho, que pode usar para otimizar ou resolver problemas de desempenho da base de dados. Uma base é um conjunto personalizado de instantâneos da base de dados que medem o desempenho e o comportamento padrão de uma base de dados para uma configuração e uma carga de trabalho específicas.
Para ver informações sobre eventos de espera no relatório de resumo de desempenho, consulte o artigo Referência do relatório de resumo de desempenho da base de dados.
Funções necessárias
Certifique-se de que tem a função de alloydbsuperuser.
Por predefinição, o AlloyDB concede a função pg_monitor a alloydbsuperuser. Para mais informações, consulte o artigo Funções predefinidas do PostgreSQL.
Se preferir usar as outras funções definidas por si, execute primeiro GRANT pg_monitor TO my_user como alloydbsuperuser. Para mais
informações, consulte o artigo
Atualize uma conta de gestão de identidade e de acesso (IAM) com a função adequada.
Crie instantâneos
As capturas instantâneas de desempenho são uma ferramenta poderosa para compreender e otimizar o desempenho da sua base de dados. Capturam as principais métricas do sistema num ponto específico no tempo, o que lhe permite comparar o desempenho da sua base de dados entre dois pontos no tempo. O AlloyDB suporta dois tipos de capturas instantâneas:
- Capturas instantâneas das métricas do sistema: estas capturas instantâneas capturam as principais métricas do sistema, como a utilização da vCPU, a utilização da memória e a E/S do disco.
- Capturas instantâneas das métricas do sistema e das estatísticas de execução de SQL: estas capturas instantâneas contêm todas as métricas do sistema de uma captura instantânea padrão, além de estatísticas de execução de SQL detalhadas da extensão
pg_stat_statements.
Isto dá-lhe a flexibilidade de escolher o nível de detalhe de que precisa para a sua análise.
Crie um instantâneo das métricas do sistema
Crie um instantâneo no início e no fim da carga de trabalho que lhe interessa. O intervalo de tempo entre as duas capturas de ecrã deve ser suficientemente longo para captar uma amostra representativa da carga de trabalho.
Siga estes passos para otimizar o desempenho da base de dados do AlloyDB:
- Crie instantâneos de base quando a base de dados estiver inativa ou quando tiver uma carga média.
- Associe um cliente
psqla uma instância do AlloyDB. Corrida
SELECT perfsnap.snap(). O resultado tem um aspeto semelhante ao seguinte:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)O resultado deste comando devolve o ID do instantâneo (
snap_id), que é1neste exemplo. Precisa deste ID para gerar um relatório de resumo do desempenho mais tarde. É provável que osnap_idno seu próprio ambiente seja diferente.Compare os relatórios que criou com ambos os conjuntos de capturas de ecrã e identifique alterações que possam melhorar o desempenho. Para mais informações sobre as recomendações de desempenho, consulte o artigo Recomendações de otimização do desempenho da base de dados.
Depois de obter métricas do relatório de resumo de desempenho resultante, pode tirar outro conjunto de capturas de ecrã e repetir o processo.
Crie um instantâneo que contenha estatísticas de execução de SQL
Por predefinição, o AlloyDB usa a extensão pg_stat_statements para acompanhar as declarações SQL. Para incluir estatísticas de execução de SQL detalhadas no relatório de desempenho, primeiro tem de criar a extensão pg_stat_statements na base de dados postgres. Tenha em atenção que a captura destas estatísticas é ativada pela flag pg_stat_statements.track e não pela criação da própria extensão.
Para criar uma captura instantânea que também contenha estatísticas de execução de SQL, siga estes passos:
- Crie a extensão
pg_stat_statementsna base de dadospostgres.postgres=# CREATE EXTENSION pg_stat_statements;
- Agora, quando tira uma captura instantânea, esta inclui automaticamente as estatísticas de SQL do
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Veja uma lista de resumos
- Associe um cliente
psqla uma instância do AlloyDB. - Corrida
SELECT * FROM perfsnap.g$snapshots. O resultado tem um aspeto semelhante ao seguinte: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)
Gere um relatório de resumo de desempenho
Para gerar um relatório que capture a diferença entre dois resumos, por exemplo, os resumos 1 e 2, execute o seguinte comando:SELECT perfsnap.report(1,2)
A segunda imagem instantânea numa operação diferencial não tem de seguir imediatamente a primeira imagem instantânea. No entanto, certifique-se de que captura a segunda imagem instantânea no diferencial após a primeira imagem instantânea.
Exemplo de relatório
Segue-se um exemplo abreviado de um relatório de resumo do desempenho gerado:
Exemplo de relatório de resumo de desempenho
$ 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 obter informações sobre os campos de relatórios e as recomendações de otimização do desempenho, consulte o artigo Recomendações de otimização do desempenho da base de dados. Para mais informações acerca dos eventos de espera nos relatórios de resumo de desempenho, consulte a referência do relatório de resumo de desempenho da base de dados.
Elimine um instantâneo
Antes de poder eliminar as imagens instantâneas que fazem parte de uma base de referência existente, tem de limpar a base de referência.
Para eliminar uma captura de ecrã, execute o seguinte comando:
SELECT perfsnap.delete(SNAP_ID);
Substitua SNAP_ID pelo ID da captura instantânea que quer eliminar.
Depois de eliminar uma captura de ecrã, não é possível recuperá-la.
Marque uma análise rápida como base de referência de desempenho
Para marcar todas as capturas instantâneas com IDs entre 1 e 3, por exemplo, como uma base de referência de desempenho do sistema, execute SELECT perfsnap.make_baseline(1, 3).
Limpe as bases de referência de desempenho
Para limpar todas as linhas de base com IDs entre 1 e 3, por exemplo, execute o comando
SELECT perfsnap.clear_baseline(1, 3).
Modifique a frequência dos instantâneos automáticos
Para personalizar a frequência das capturas de ecrã automáticas, defina a flag perfsnap.interval, que define o intervalo de capturas de ecrã automáticas em segundos. Para mais informações, consulte o artigo
Configure flags da base de dados.
Recomendamos que defina o valor da flag, pelo menos, vários minutos para captar informações significativas.
Para evitar o desperdício de recursos, quando já não precisar da frequência personalizada, reponha a flag para o valor predefinido (que é segundos por dia).
Otimize o desempenho da base de dados com os resultados do relatório de instantâneo
Siga estes passos para otimizar o desempenho da base de dados do AlloyDB:
- Crie instantâneos de base quando a base de dados estiver inativa ou quando estiver a registar uma carga média.
- Inicie a carga de trabalho ou a consulta cujo desempenho quer melhorar.
- Quando a carga de trabalho ou a consulta atingir o pico de utilização de recursos, crie outro conjunto de instantâneos. Recomendamos que use o mesmo intervalo para ambos os relatórios.
- Compare os relatórios que criou com ambos os conjuntos de capturas de ecrã e identifique alterações que possam melhorar o desempenho. Para mais informações sobre as recomendações de desempenho, consulte o artigo Recomendações de otimização do desempenho da base de dados.
Recomendações de otimização do desempenho da base de dados
A tabela seguinte lista as secções do relatório de resumo de desempenho e as melhorias recomendadas para cada secção do relatório. Para mais informações sobre as secções do relatório de resumo de desempenho e os eventos de espera, consulte a referência do relatório de resumo de desempenho da base de dados.
| Secção | Campo do relatório | Descrição do campo do relatório | Recomendações de otimização |
|---|---|---|---|
| Detalhes do instantâneo | Detalhes do instantâneo | Fornece o anfitrião, a versão de lançamento compatível com o PostgreSQL e a hora em que a máquina está em funcionamento. | N/A |
| ID do resumo | Apresenta o ID e o momento específico dos instantâneos usados para criar este relatório. | N/A | |
| Estatísticas do sistema | CPU do anfitrião | Detalhes da utilização da CPU do anfitrião. | Se a utilização da CPU for superior a 80%, recomendamos que aumente a escala para o tamanho disponível seguinte. |
| Memória do anfitrião | Detalhes da utilização da memória do anfitrião. | Se a memória livre for inferior a 15%, recomendamos que aumente para o tamanho disponível seguinte. | |
| Carregar perfil | Lista os contadores que ajudam a qualificar a sua carga de trabalho de registo antecipado (WAL) gerado, requisitos de E/S e gestão de ligações. | Se as leituras físicas forem superiores às leituras lógicas, considere aumentar a escala para o tamanho disponível seguinte para suportar uma colocação em cache de dados maior. | |
| Tempo de resposta e discriminação da classe de espera | Análise detalhada do tempo que o Postgres processou durante a execução da carga de trabalho. | Concentre a otimização na redução do tempo de espera de E/S se os processos estiverem principalmente num estado de espera, por exemplo. | |
| Informações sobre a carga de trabalho da base de dados | Informações sobre a carga de trabalho por base de dados | Métricas principais para cada base de dados, incluindo commits, reversões, taxa de acertos e informações sobre tabelas temporárias e operações de ordenação. | Se os reversões forem elevadas, considere diagnosticar a sua app. |
| Informações de DML e DQL por base de dados | Contadores para operações de consulta. | Qualifique a sua carga de trabalho como de leitura intensiva ou de escrita intensiva. | |
| Informações de conflitos da base de dados | Contadores para problemas comuns de aplicações e bases de dados. | Localize problemas na sua aplicação se existir um impasse. | |
| Informações sobre o dimensionamento da base de dados | Mostra o crescimento da base de dados durante o intervalo entre duas imagens instantâneas. Este campo também mostra se a base de dados tem limites de associação estabelecidos. | Localize problemas na sua aplicação se o crescimento da base de dados for demasiado grande. | |
| Informações sobre o aspirador | Informações sobre o aspirador | Detalhes de E/S e contadores para operações de vácuo. | Por predefinição, o AlloyDB realiza a limpeza de dados adaptável. Pode substituir algumas das definições de limpeza para se adequarem à sua carga de trabalho. Por exemplo, reduza as operações de vácuo se for gasto demasiado I/O nestes pedidos. |
| Informações de vácuo por base de dados | Mostra as seguintes informações:
|
Se a idade do campo XID congelado for demasiado antiga ou se a percentagem de transações consumidas estiver perto de 90%, considere fazer a limpeza. Se o intervalo de vácuo agregado diminuir, isto indica que o Postgres vai aplicar um vácuo para evitar a repetição. | |
| Detalhes de espera dos processos da base de dados | Informações detalhadas sobre processos de back-end e em segundo plano | Detalhes de todas as esperas por processos de back-end e em segundo plano no intervalo do relatório. As informações incluem o tempo de espera cumulativo, o tempo da CPU e o tempo médio por tipo de espera. | Para diminuir o tempo de espera em WALWrite, por exemplo, aumente o número de wal_buffers disponíveis para a base de dados. |
| Histograma detalhado de eventos de espera de back-end e em segundo plano | Esta opção está incluída no relatório de resumo de desempenho por predefinição. A lista contém o histograma de eventos de espera para processos de back-end e em segundo plano, que estão divididos em 32 recipientes, de 1 us a mais de 16 segundos. | Localize os eventos de espera e determine se existem demasiados eventos de espera no intervalo de tempo de espera maior. Pode haver um problema com demasiados eventos de espera ou com cada tempo de espera consumido. | |
| Estatísticas diversas | Estatísticas do registo de gravação antecipada (WAL) | Resumo das estatísticas de WAL. | Se tiver um tempo de sincronização demasiado longo, ajuste as flags da base de dados relacionadas (GUC) para melhorar a sua carga de trabalho. GUC é o subsistema PostgreSQL que processa a configuração do servidor. |
| Estatísticas de resumo (em todas as bases de dados) | Resumo de todas as operações da base de dados que ocorrem durante o intervalo do instantâneo. | N/A | |
| Definições de parâmetros | Definições de parâmetros | Parâmetros de configuração do Postgres principais no momento da captura de ecrã final. | Verifique as definições do parâmetro GUC (as flags da base de dados Postgres) para determinar se os valores não são esperados ou não são recomendados. |
| Estatísticas de execução de SQL | Informações por consulta (50 principais) por tempo decorrido total | Apresenta as 50 principais consultas que gastaram mais tempo decorrido durante as duas capturas de ecrã, bem como a respetiva contagem total de execuções, discriminadas pelo utilizador e pela base de dados onde a consulta é emitida.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
Use esta secção para identificar a consulta mais pesada que demora mais tempo do sistema. |
| Informações por consulta (50 principais) por leitura de IO | Apresenta as 50 principais consultas que gastaram mais tempo de leitura de E/S durante as duas capturas de ecrã, bem como a respetiva contagem de execuções, ocorrências de buffer e leituras de blocos, no total e em média.ReadIO = blk_read_time + temp_blk_read_time acumulados durante as duas capturas de ecrãBuffer Hits = shared_blks_hit + local_blks_hit acumulados durante as duas capturas de ecrãBuffer Reads = shared_blks_read + local_blks_read acumulados durante as duas capturas de ecrãEstes campos são monitorizados pelo AlloyDB Cloud por predefinição, uma vez que track_io_timing está definido. |
Use esta secção para identificar consultas com utilização intensiva de E/S, especialmente se precisarem de ler dos discos com frequência. | |
| Informações por consulta (50 principais) por desvio padrão do tempo decorrido | Apresente uma lista das 50 principais consultas com o desvio padrão mais elevado do tempo decorrido, apresentando os desvios padrão calculados no momento da captura de ecrã inicial e final. Aqui, o valor faz referência a stddev_exec_time de pg_stat_statements |
Para uma consulta com um desvio padrão elevado, significa que o tempo de execução da consulta varia muito e pode ser altura de analisar a E/S. |
Limitações
Para evitar o aumento do espaço devido ao consumo excessivo de armazenamento, pode criar manualmente um máximo de 2500 instantâneos numa instância.
Se o número de instantâneos exceder o limite de instantâneos, o AlloyDB elimina todos os instantâneos manuais com mais de 90 dias. Para permanecer dentro do limite de resumos, tem de limpar os resumos desnecessários antes de criar um novo.
O AlloyDB limpa periodicamente as cópias instantâneas manuais com mais de 90 dias.
O que se segue?
- Saiba mais acerca dos eventos de espera nos relatórios de resumo de desempenho.