Para identificar e atenuar problemas de performance do banco de dados do AlloyDB para PostgreSQL, compare snapshots de métricas do sistema entre dois pontos no tempo gerando relatórios de snapshot de performance manualmente. As métricas do sistema capturadas em cada snapshot incluem o uso da CPU virtual (vCPU), o uso da memória, a E/S de disco, a contagem de transações e os eventos de espera.
Snapshots automáticos e manuais
O AlloyDB oferece suporte aos seguintes snapshots:
Snapshots automáticos:por padrão, o AlloyDB captura snapshots automaticamente uma vez por dia e os armazena por sete dias. Os snapshots automáticos ajudam a gerar relatórios com granularidade de carga de trabalho diária. É possível configurar a frequência e a retenção de um snapshot automático.
Snapshots manuais:é possível capturar snapshots e gerar relatórios manualmente.
Você pode combinar snapshots automáticos e manuais para gerar relatórios de performance. Por exemplo, é possível gerar um relatório de snapshot de performance que compara um snapshot gerado manualmente a um snapshot automático.
Este documento descreve como gerar relatórios de snapshot de performance manualmente.
Como os relatórios de snapshot de performance funcionam
Os relatórios de snapshot de performance são uma ferramenta integrada do AlloyDB que captura e analisa dados de performance para ajudar a identificar a causa de problemas de performance. Essa ferramenta complementa outros recursos de observabilidade do AlloyDB, como insights do sistema, insights de consultas, e o Metrics Explorer, que fornecem métricas em tempo real sobre sua instância.
Os relatórios de snapshot de performance mostram as métricas do banco de dados entre dois carimbos de data/hora em um único relatório. É possível usar as informações do Performance Snapshot Report para identificar problemas de desempenho com a instância do Performance Snapshot Report, como a diminuição do desempenho do banco de dados durante determinados horários do dia ou a diminuição do desempenho durante um determinado período. Quando usado em um nó de pool de leitura, o relatório ajuda a identificar se o atraso de replicação é causado por restrições de recursos do sistema, como CPU ou memória, ou conflitos de consulta específicos, como fixações de buffer.
Usando o Performance Snapshot Report, você compara as métricas a uma linha de base de performance para ter insights sobre as métricas de performance da carga de trabalho, que podem ser usadas para otimizar ou solucionar problemas de performance do banco de dados. Uma linha de base é um conjunto personalizado de snapshots de banco de dados que mede a performance e o comportamento padrão de um banco de dados para uma configuração e carga de trabalho específicas.
Para informações sobre eventos de espera no relatório de snapshot de performance, consulte Referência do relatório de snapshot de performance do banco de dados.
Funções exigidas
Verifique se você tem a função alloydbsuperuser.
Por padrão, o AlloyDB concede a função pg_monitor ao alloydbsuperuser. Para mais informações, consulte
Papéis predefinidos do PostgreSQL.
Se você preferir usar suas outras funções autodefinidas, execute GRANT pg_monitor TO my_user como alloydbsuperuser primeiro. Para mais
informações, consulte
Atualizar uma conta do Identity and Access Management (IAM) com a função apropriada.
Criar snapshots
Os snapshots de performance são uma ferramenta poderosa para entender e otimizar a performance do banco de dados. Eles capturam as principais métricas do sistema em um momento específico, permitindo comparar a performance do banco de dados entre dois pontos no tempo. O AlloyDB oferece suporte a dois tipos de snapshots:
- Snapshots de métricas do sistema:esses snapshots capturam as principais métricas do sistema, como uso da vCPU, uso da memória e E/S de disco.
- Snapshots de métricas do sistema e estatísticas de execução de SQL:esses snapshots contêm todas as métricas do sistema de um snapshot padrão, além de estatísticas detalhadas de execução de SQL da extensão
pg_stat_statements.
Isso oferece a flexibilidade de escolher o nível de detalhes necessário para sua análise.
Criar um snapshot de métricas do sistema
Crie um snapshot no início e no fim da carga de trabalho em que você está interessado. O intervalo de tempo entre os dois snapshots precisa ser longo o suficiente para capturar uma amostra representativa da carga de trabalho.
Siga estas etapas para otimizar a performance do banco de dados do AlloyDB:
- Crie snapshots de linha de base quando o banco de dados estiver inativo ou quando estiver com uma carga média.
- Conecte um cliente
psqla uma instância do AlloyDB. Para um nó de pool de leitura, é necessário se conectar diretamente ao endereço IP. Para mais informações, consulte Recuperar a lista de endereços IP de nós do pool de leitura. Execute
SELECT perfsnap.snap(). A saída será assim:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)A saída desse comando retorna o ID do snapshot (
snap_id), que é1neste exemplo. Você precisa desse ID para gerar um relatório de snapshot de performance mais tarde. Osnap_idno seu ambiente provavelmente é diferente.Compare os relatórios criados com os dois conjuntos de snapshots e identifique as mudanças que podem melhorar a performance. Para mais informações sobre recomendações de performance, consulte Recomendações de otimização de performance do banco de dados.
Depois de obter métricas do Performance Snapshot Report resultante, você pode criar outro conjunto de snapshots e repetir o processo.
Criar um snapshot que contenha estatísticas de execução de SQL
Por padrão, o AlloyDB 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 é necessário criar 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 de SQL de
pg_stat_statements.postgres=# select perfsnap.snap(); snap ------ 2 (1 row)
Ver uma lista de snapshots
- Conecte um cliente
psqla uma instância do AlloyDB. Para um nó de pool de leitura, é necessário se conectar diretamente ao endereço IP usandopsql. Para mais informações, consulte Recuperar a lista de endereços IP de nós do pool de leitura. - Execute
SELECT * FROM perfsnap.g$snapshots. A saída 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 | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Automatic snapshot| Automatic | f 3 | 2023-11-13 22:56:42.57094+00 | perf-replica | sab3-perf-replica-b9250422-tz4n | Automatic snapshot| Automatic | f 4 | 2023-11-13 22:56:42.59476+00 | perf-replica | sab3-perf-replica-b9250422-63q3 | Automatic snapshot| Automatic | f 5 | 2023-11-13 23:11:55.23157+00 | perf-replica | sab3-perf-replica-b9250422-tz4n | Manual snapshot | Manual | f (5 rows)
Gerar um relatório de snapshot de performance
Para gerar um relatório que capture a diferença entre dois snapshots, por exemplo, os snapshots 1 e 2, execute:SELECT perfsnap.report(1,2)
O segundo snapshot em uma operação diferencial não precisa seguir imediatamente o primeiro snapshot. No entanto, capture o segundo snapshot no diferencial após o primeiro snapshot.
O relatório de snapshot de performance gerado é semelhante ao exemplo abreviado a seguir.
Exemplo de relatório
Confira a seguir um exemplo abreviado de um relatório de snapshot de performance gerado:
Exemplo de relatório de snapshot de performance
$ 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 informações sobre campos de relatório e recomendações de otimização de performance, consulte Recomendações de otimização de performance do banco de dados. Para mais informações sobre eventos de espera em relatórios de snapshot de performance, consulte Referência do relatório de snapshot de performance do banco de dados.
Excluir um snapshot
Antes de excluir snapshots que fazem parte de uma linha de base atual, é necessário limpar a linha de base.
Para excluir um snapshot, execute o seguinte comando:
SELECT perfsnap.delete(SNAP_ID);
Substitua SNAP_ID pelo ID do snapshot que você quer excluir.
Depois de excluir um snapshot, não é possível recuperá-lo.
Marcar um snapshot como uma linha de base de performance
Para marcar todos os snapshots com IDs entre 1 e 3, por exemplo, como uma linha de base de performance do sistema, execute SELECT perfsnap.make_baseline(1, 3).
Limpar linhas de base de performance
Para limpar todas as linhas de base com IDs entre 1 e 3, por exemplo, execute SELECT perfsnap.clear_baseline(1, 3).
Modificar a frequência de snapshots automatizados
Os snapshots automatizados são criados para a instância principal e nós de leitura uma vez por dia por padrão.
Para personalizar a frequência de snapshots automatizados, defina a flag perfsnap.interval, que define o intervalo de snapshot automático em segundos. Para mais informações, consulte
Configurar flags de banco de dados.
Recomendamos definir o valor da flag como pelo menos vários minutos para capturar informações significativas.
Para otimizar o uso de recursos, quando você não precisar mais da frequência personalizada, redefina a flag para o valor padrão, que é de 86.400 segundos por dia.
Modificar a retenção de snapshots automatizados
Para personalizar o período de armazenamento de snapshots automatizados, defina a flag perfsnap.retention, que define a duração em que os snapshots automáticos são mantidos. Para mais informações, consulte
Configurar flags de banco de dados.
O período de armazenamento padrão é 7 days.
Otimizar a performance do banco de dados usando os resultados do relatório de snapshot
Siga estas etapas para otimizar a performance do banco de dados do AlloyDB:
- Crie snapshots de linha de base quando o banco de dados estiver inativo ou quando estiver com uma carga média.
- Inicie a carga de trabalho ou a consulta cuja performance você quer melhorar.
- Quando a carga de trabalho ou a consulta atingir o uso máximo de recursos, crie outro conjunto de snapshots. Recomendamos usar o mesmo intervalo para os dois relatórios.
- Compare os relatórios criados com os dois conjuntos de snapshots e identifique as mudanças que podem melhorar a performance. Para mais informações sobre recomendações de performance, consulte Recomendações de otimização de performance do banco de dados.
Recomendações de otimização de performance do banco de dados
A tabela a seguir lista as seções do Performance Snapshot Report e as melhorias recomendadas para cada seção do relatório. Para mais informações sobre as seções do relatório de snapshot de performance e eventos de espera, consulte Referência do relatório de snapshot de performance do banco de dados.
| Seção | Campo do relatório | Descrição do campo 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 funcionamento. | N/A |
| ID do snapshot | Lista o ID e o momento dos snapshots usados para criar esse relatório. | N/A | |
| Insights do Sistema | CPU do host | Detalhes de uso da CPU do host. | Se o uso da CPU for maior que 80%, recomendamos que você escalonar verticalmente para o próximo tamanho disponível. Para instâncias de pool de leitura, verifique se o tamanho do nó é igual ou maior que a instância principal. Nós de leitura menores podem não conseguir acompanhar a taxa de geração de WAL da instância principal durante cargas de trabalho de gravação pesadas. |
| Memória do host | Detalhes de uso de memória do host. | Se a memória livre for menor que 15%, recomendamos que você escalonar verticalmente para o próximo tamanho disponível. Para instâncias de pool de leitura, verifique se o tamanho do nó é igual ou maior que a instância principal. Nós de leitura menores podem não conseguir acompanhar a taxa de geração de WAL da instância principal durante cargas de trabalho de gravação pesadas. | |
| Carregar perfil | Lista contadores que ajudam a qualificar sua carga de trabalho de registro gravado com antecedência (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 leituras lógicas, considere fazer o escalonamento vertical para o próximo tamanho disponível para oferecer suporte a um cache maior de dados. | |
| Tempo de resposta e detalhamento da classe de espera | Detalhamento do tempo gasto pelos processos do Postgres durante a execução da carga de trabalho. | Concentre o ajuste no encurtamento da espera de E/S se os processos estiverem principalmente em um estado de espera, por exemplo. | |
| Informações da carga de trabalho do banco de dados | Informações da carga de trabalho por banco de dados | Métricas principais para cada banco de dados, incluindo commits, reversões, taxa de acertos e informações sobre tabelas temporárias e operações de classificação. | Se os rollbacks forem altos, considere diagnosticar seu app. |
| Informações de DML e DQL por banco de dados | Contadores para operações de consulta. | Qualifique sua carga de trabalho como leitura pesada ou gravação pesada. | |
| Informações de conflito do banco de dados | Contadores para problemas comuns de aplicativos e bancos de dados. | Localize problemas no aplicativo se houver um deadlock. Se os conflitos de fixações de buffer forem altos em uma instância de pool de leitura, considere reduzir o valor max_standby_streaming_delay para permitir que a reprodução continue ou mova consultas de longa duração para um pool de leitura diferente para evitar manter fixações por períodos prolongados. |
|
| 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 de vácuo | Informações de vácuo | Detalhes de E/S e contadores para operações de vácuo. | Por padrão, o AlloyDB realiza a limpeza adaptativa. É possível substituir algumas das configurações de vácuo para atender à sua carga de trabalho. Por exemplo, reduza as operações de vácuo se muita E/S for gasta nessas solicitações. |
| Informações de vácuo por banco de dados | Mostra as seguintes informações:
|
Se a idade do campo XID congelado for muito antiga ou se a porcentagem de transações consumidas estiver próxima de 90%, considere a limpeza. Se a lacuna de vácuo agregada diminuir, isso indica que um vácuo será aplicado pelo Postgres para evitar o wraparound. | |
| Detalhes de espera de processos do banco 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 de CPU e o tempo médio por tipo de espera. | Para diminuir a espera no 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 está incluído no relatório de snapshot de performance 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 consumido de espera. | |
| Estatísticas diversas | Estatísticas de registro gravado com antecedência (WAL) | Resumo das estatísticas de WAL. | Se você tiver muito tempo de sincronização, ajuste as flags de banco de dados relacionadas (GUC) para melhorar sua carga de trabalho. O GUC é o subsistema do PostgreSQL que processa 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 | Parâmetros de configuração principais do Postgres no horário do snapshot final. | Verifique as configurações de parâmetros do GUC (as flags do banco de dados do Postgres) para determinar se os
valores não são esperados ou não são recomendados. Para instâncias de pool de leitura
que apresentam um atraso de replicação alto, considere ajustar o seguinte:
|
| Estatísticas de execução de SQL | Informações por consulta (50 principais) por tempo total decorrido | Lista as 50 principais consultas que gastaram mais tempo decorrido durante os dois snapshots, bem como a contagem total de execução, detalhada 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 a maior parte do tempo do sistema. |
| Informações por consulta (50 principais) por E/S de leitura | Lista as 50 principais consultas que gastaram mais tempo de E/S de leitura durante os dois snapshots, bem como a contagem de execução, acertos de buffer, leituras de bloco, tanto no total quanto na 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 por padrão, já que track_io_timing está definido. |
Use esta seção para identificar consultas com uso intenso de E/S, especialmente se elas precisarem ler dos discos com frequência. | |
| Informações por consulta (50 principais) por desvio padrão do tempo decorrido | Lista as 50 principais consultas que têm o maior desvio padrão do tempo decorrido, listando os desvios padrão calculados no início e no fim do snapshot. Aqui, o valor faz referência a stddev_exec_time de pg_stat_statements |
Para consultas com alto desvio padrão, isso significa que o tempo de execução da consulta varia muito e pode ser hora de analisar a E/S. |
Limitações
Para evitar o aumento do espaço devido ao consumo excessivo de armazenamento, é possível criar manualmente um máximo de 2.500 snapshots em uma instância.
Se o número de snapshots exceder o limite de snapshots, o AlloyDB vai excluir todos os snapshots manuais com mais de 90 dias. Para permanecer dentro do limite de snapshots, é necessário limpar os snapshots desnecessários antes de criar um novo.
O AlloyDB limpa periodicamente os snapshots manuais com mais de 90 dias.
A seguir
- Saiba mais sobre eventos de espera em relatórios de snapshot de performance.