Como funcionam os Performance Snapshot Reports
Os relatórios de snapshot de desempenho são uma ferramenta integrada do AlloyDB Omni que captura e analisa dados de desempenho para ajudar a identificar a causa de problemas de desempenho.
Os relatórios de Performance Snapshot mostram métricas do banco de dados entre dois carimbos de data/hora em um único relatório. Use as informações do Performance Snapshot Report para identificar problemas de desempenho com a instância do Performance Snapshot Report, como diminuição do desempenho do banco de dados durante determinados horários do dia ou diminuição do desempenho em um determinado período.
Usando o Performance Snapshot Report, você compara as métricas com um valor de referência de desempenho para receber insights sobre as métricas de desempenho da carga de trabalho, que podem ser usadas para otimizar ou resolver problemas de desempenho do banco de dados. Uma linha de base é um conjunto personalizado de snapshots de banco de dados que medem o desempenho e o comportamento padrão de um banco de dados para uma configuração e carga de trabalho específicas.
Por padrão, os snapshots de desempenho no AlloyDB Omni são armazenados na memória e descartados se a instância for reiniciada.
Funções exigidas
Verifique se você tem o papel pg_monitor.
Esse papel é concedido a superusuários, que podem conceder pg_monitor a outros usuários.
Por exemplo, postgres é o superusuário por padrão. É possível executar
GRANT pg_monitor TO my_user como postgres para permitir que my_user use a ferramenta de snapshot de desempenho, conforme descrito neste documento.
Instalar o Performance Snapshot Report
perfsnap é o nome do esquema que contém funções SQL que permitem aos usuários capturar snapshots ou gerar relatórios. Esse esquema faz parte da extensão g_stats do AlloyDB Omni. Use o papel de superusuário para instalar o Performance Snapshot Report.
Para usar as APIs perfsnap, conecte-se a qualquer banco de dados em que os usuários queiram instalar a extensão e crie a extensão g_stats com o seguinte comando:
CREATE EXTENSION IF NOT EXISTS g_stats;
Criar um snapshot das métricas do sistema
Crie um snapshot no início e no final da carga de trabalho que você quer analisar. O intervalo de tempo entre os dois snapshots permite que a carga de trabalho progrida para que o sistema possa acumular métricas que reflitam a carga de trabalho. Depois de obter métricas do Performance Snapshot Report resultante, você pode criar outro conjunto de snapshots e repetir o processo.
- Conectar um cliente
psqla uma instância do AlloyDB. Execute
SELECT perfsnap.snap(). A saída será assim:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Criar um snapshot que contenha estatísticas de execução de SQL
Por padrão, o AlloyDB Omni usa a extensão pg_stat_statements para rastrear instruções SQL. Para incluir estatísticas detalhadas de execução de SQL no relatório de performance, primeiro crie a extensão pg_stat_statements no banco de dados postgres. A captura dessas estatísticas é ativada pela flag pg_stat_statements.track, não pela criação da extensão em si.
Para criar um snapshot que também contenha estatísticas de execução de SQL, siga estas etapas:
Crie a extensão
pg_stat_statementsno banco de dadospostgres.postgres=# CREATE EXTENSION pg_stat_statements;Agora, quando você cria um snapshot, ele inclui automaticamente as estatísticas SQL de
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Ver uma lista de snapshots
- Conectar um cliente
psqla uma instância do AlloyDB. Execute
SELECT * FROM perfsnap.g$snapshots. A resposta será assim: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)
Gerar um relatório de snapshot
Para gerar um relatório que capture a diferença entre os snapshots 1
e 2, por exemplo, execute SELECT perfsnap.report(1,2).
O segundo snapshot em uma operação diferencial não precisa seguir imediatamente o primeiro. No entanto, capture o segundo snapshot no diferencial após o primeiro.
O relatório de Performance Snapshot gerado é semelhante ao seguinte exemplo resumido:
Exemplo de Performance Snapshot Report
psql -d postgres -U 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
----------------------------------------------------
(rows)
Para informações sobre campos de relatório e recomendações de otimização de desempenho, consulte Recomendações de otimização de desempenho do banco de dados. Para mais informações sobre eventos de espera em relatórios de Performance Snapshot, consulte Referência do relatório de Performance Snapshot do banco de dados.
Excluir um snapshot
Antes de excluir snapshots que fazem parte de um baseline, é preciso limpar o baseline .
Para excluir um snapshot, execute SELECT perfsnap.delete(n). Depois de excluir um
snapshot, não é possível recuperá-lo.
Marcar um snapshot como referência de desempenho
Para marcar todos os snapshots com IDs entre 1 e 3, por exemplo, como um valor de referência de desempenho do sistema, execute SELECT perfsnap.make_baseline(1, 3).
Limpar os valores de referência de desempenho
Para limpar todas as referências com IDs entre 1 e 3, por exemplo, execute
SELECT perfsnap.clear_baseline(1, 3).
Otimizar o desempenho do banco de dados usando os resultados do relatório de snapshot
Siga estas etapas para otimizar o desempenho do banco de dados do AlloyDB:
- Crie snapshots de referência quando o banco de dados estiver inativo ou quando estiver com uma carga média.
- Inicie a carga de trabalho ou consulta que você quer melhorar.
- Quando a carga de trabalho ou a consulta atingir o pico de uso de recursos, crie outro conjunto de snapshots. Recomendamos que você use o mesmo intervalo para os dois relatórios.
- Compare os relatórios que você criou com os dois conjuntos de snapshots e identifique mudanças que podem melhorar o desempenho. Para mais informações sobre recomendações de desempenho, consulte Recomendações de otimização de desempenho do banco de dados.
Recomendações de otimização de desempenho do banco de dados
A tabela a seguir lista as seções do relatório de snapshot de desempenho e as melhorias recomendadas para cada seção. Para mais informações sobre as seções do relatório de snapshot de desempenho e os eventos de espera, consulte Referência do relatório de snapshot de desempenho do banco de dados.
| Seção | Campo do relatório | Descrição dos campos do relatório | Recomendações de otimização |
|---|---|---|---|
| Detalhes do snapshot | Detalhes do snapshot | Fornece o host, a versão de lançamento compatível com o PostgreSQL e o horário em que a máquina está em execução. | N/A |
| ID do snapshot | Lista o ID e o momento dos snapshots usados para criar este relatório. | N/A | |
| Insights do Sistema | CPU do host | Detalhes de uso da CPU do host. | Se a utilização da CPU for maior que 80%, recomendamos que você mude para um sistema com mais vCPUs. |
| Memória do host | Detalhes do uso da memória do host. | Se a memória livre for inferior a 15%, recomendamos que você faça o escalonamento vertical para o próximo tamanho disponível. | |
| Carregar perfil | Lista contadores que ajudam a caracterizar sua carga de trabalho em termos de registro prévio de escrita (WAL, na sigla em inglês) gerado, requisitos de E/S e gerenciamento de conexões. | Se as leituras físicas forem maiores que as lógicas, considere aumentar para o próximo tamanho disponível para oferecer suporte a um armazenamento em cache maior de dados. | |
| Tempo de resposta e detalhamento da classe de espera | Detalhamento do tempo que os processos do Postgres gastaram durante a execução da carga de trabalho. | Por exemplo, concentre o ajuste na redução da espera de E/S se os processos estiverem principalmente em um estado de espera. | |
| Informações sobre a carga de trabalho do banco de dados | Informações de carga de trabalho por banco de dados | Métricas principais de cada banco de dados, incluindo confirmações, reversões, proporção de ocorrências e informações sobre tabelas temporárias e operações de classificação. | Se as reversões forem altas, considere diagnosticar o app. |
| Informações de DML e DQL por banco de dados | Contadores para operações de consulta. | Qualifique sua carga de trabalho como de leitura ou gravação intensa. | |
| Informações sobre conflitos de banco de dados | Contadores para problemas comuns de aplicativos e bancos de dados. | Localizar problemas no aplicativo se houver um impasse. | |
| Informações de dimensionamento do banco de dados |
Mostra o quanto o banco de dados cresceu durante o intervalo entre dois snapshots. Esse campo também mostra se o banco de dados tem limites de conexão estabelecidos. | Localize problemas no aplicativo se o crescimento do banco de dados for muito grande. | |
| Informações sobre o aspirador de pó | Informações do aspirador de pó | Detalhes de E/S e contadores para operações de vacuum. | Por padrão, o AlloyDB realiza a limpeza adaptativa. É possível modificar algumas das configurações de vacuum para se adequar à carga de trabalho. Por exemplo, reduza as operações de vácuo se houver muita E/S gasta nessas solicitações. |
| Informações de vacuum por banco de dados | Mostra as seguintes informações:
|
Se o campo "Idade do XID congelado" for muito antigo ou se a porcentagem de transações consumidas estiver próxima de 90%, considere fazer uma limpeza. Se o intervalo de vacuum agregado diminuir, isso indica que um vacuum será aplicado pelo Postgres para evitar o wraparound. | |
| Detalhes de espera dos processos do banco de dados | Informações detalhadas sobre back-end e processos 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 de CPU e o tempo médio por tipo de espera. | Para diminuir a espera em WALWrite, por exemplo, aumente o número de
wal_buffers disponíveis para o banco de dados. |
| Histograma detalhado de eventos de espera de back-end e em segundo plano | Isso é incluído no relatório de snapshot de desempenho por padrão. A lista contém o histograma de eventos de espera para processos de back-end e em segundo plano, que são divididos em 32 buckets, de 1 us a mais de 16 segundos. | Localize os eventos de espera e determine se há muitos eventos de espera no bucket de tempo de espera maior. Pode haver um problema com muitos eventos de espera ou com cada tempo de espera consumido. | |
| Estatísticas diversas | Estatísticas do registro prévio de escrita (WAL) | Resumo das estatísticas do WAL. | Se o tempo de sincronização for muito longo, ajuste as flags de banco de dados relacionadas (GUC) para melhorar sua carga de trabalho. GUC é o subsistema do PostgreSQL que lida com a configuração do servidor. |
| Estatísticas de resumo (em todos os bancos de dados) | Resumo de todas as operações de banco de dados que ocorrem durante o intervalo do snapshot. | N/A | |
| Configurações do parâmetro | Configurações do parâmetro | Principais parâmetros de configuração do Postgres no momento do snapshot final. | Verifique as configurações de parâmetro GUC (as flags de banco de dados do Postgres) para determinar se os valores não são esperados ou não são recomendados. |
| Estatísticas de execução do SQL | Informações por consulta (as 50 principais) por tempo total decorrido | Lista as 50 consultas que gastaram mais tempo decorrido durante os dois snapshots, bem como a contagem total de execuções, dividida pelo usuário e pelo banco de dados em que a consulta é emitida.Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time |
Use esta seção para identificar a consulta mais pesada que leva mais tempo do sistema. |
| Informações por consulta (50 principais) por E/S de leitura | Lista as 50 consultas que gastaram mais tempo de E/S de leitura durante os dois snapshots, bem como a contagem de execuções, as ocorrências de buffer e as leituras de blk, tanto no total quanto em média.ReadIO = blk_read_time + temp_blk_read_time acumulado durante os dois snapshotsBuffer Hits = shared_blks_hit + local_blks_hit acumulado durante os dois snapshotsBuffer Reads = shared_blks_read + local_blks_read acumulado durante os dois snapshotsEsses campos são rastreados pelo AlloyDB Cloud por padrão, já que track_io_timing está definido. |
Use esta seção para identificar consultas com uso intensivo de E/S, especialmente se elas precisarem ler discos com frequência. | |
| Informações por consulta (as 50 principais) por desvio padrão do tempo decorrido | Liste as 50 principais consultas que têm o maior desvio padrão de tempo decorrido, listando os desvios padrão calculados no horário do snapshot de início e de término. Aqui, o valor faz referência a stddev_exec_time de pg_stat_statements |
Para consultas com desvio padrão alto, isso significa que o tempo de execução varia muito, e pode ser hora de analisar a E/S. |
Limitações
Para evitar o excesso de espaço, é possível criar manualmente no máximo 2.500 snapshots em uma instância. O bloat de espaço garante que os snapshots não ocupem muito espaço de armazenamento no banco de dados.
Se o número de snapshots exceder o limite, o AlloyDB Omni vai excluir todos os snapshots manuais com mais de 90 dias. Para permanecer dentro do limite de snapshots, limpe os snapshots desnecessários antes de criar um novo.
O AlloyDB Omni limpa periodicamente os snapshots manuais com mais de 90 dias.
A seguir
- Saiba mais sobre eventos de espera em relatórios de Performance Snapshot.