Comparar snapshots de desempenho para otimizar o desempenho do banco de dados

Este documento descreve como identificar e reduzir problemas de desempenho do banco de dados AlloyDB Omni usando um relatório que compara snapshots de métricas do sistema entre dois pontos diferentes no tempo. As métricas do sistema capturadas em cada instantâneo incluem uso de CPU virtual (vCPU), uso de memória, E/S de disco, contagem de transações e eventos de espera.

Como os relatórios de snapshot de performance funcionam

Os relatórios de resumo de desempenho são uma ferramenta integrada do AlloyDB Omni que captura e analisa dados de desempenho para ajudar a identificar a causa dos problemas de performance. Essa ferramenta complementa outros recursos de observabilidade do AlloyDB Omni, como insights de sistemas, insights de consulta e o Metrics Explorer, que fornecem métricas em tempo real sobre sua instância.

Os relatórios de resumo de desempenho 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 relatório de resumo de performance para identificar problemas de desempenho com a instância do relatório de resumo de performance, como redução no desempenho do banco de dados em determinados horários do dia ou redução no desempenho em um determinado período.

Com o relatório de resumo de performance, você compara as métricas a um valor de referência de performance para ter insights sobre as métricas de performance 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 mede o desempenho 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 desempenho, consulte Referência do relatório de snapshot de desempenho do banco de dados.

Funções exigidas

Verifique se você tem o papel alloydbsuperuser. Por padrão, o AlloyDB concede o papel pg_monitor a alloydbsuperuser. Para mais informações, consulte Papéis predefinidos do PostgreSQL.

Se você preferir usar 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 o papel apropriado.

Instalar o relatório de resumo de performance

perfsnap é o nome do esquema que contém funções SQL que permitem que os usuários capturem instantâneos ou gerem relatórios. Esse esquema faz parte da extensão g_stats do AlloyDB Omni. Use a função de superusuário para instalar o relatório de resumo de desempenho.

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 fim da carga de trabalho de seu interesse. 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 receber as métricas do relatório de snapshot de performance resultante, você pode fazer outro conjunto de snapshots e repetir o processo.

  1. Conecte um cliente psql a uma instância do AlloyDB.
  2. Execute SELECT perfsnap.snap(). A saída será assim:

    postgres=# select perfsnap.snap();
     snap
    ------
        1
    (1 row)
    

Conferir uma lista de snapshots

  1. Conecte um cliente psql a uma instância do AlloyDB Omni.
  2. Execute SELECT * FROM perfsnap.g$snapshots. A saída será semelhante a esta:

    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 instantâneos 1 e 2, por exemplo, execute
SELECT perfsnap.report(1,2).

O segundo instantâneo 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 resumo de desempenho gerado é semelhante ao exemplo resumido a seguir:

Exemplo de relatório de resumo 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

 ----------------------------------------------------
 Created by G_STATS v1.0.100
 ----------------------------------------------------
(xxx rows)

  

Para informações sobre campos de relatórios 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 snapshots de desempenho, consulte Referência do relatório de snapshots de desempenho do banco de dados.

Excluir um snapshot

Antes de excluir snapshots que fazem parte de uma base de referência, é necessário limpar a base de referência .

Para excluir um snapshot, execute SELECT perfsnap.delete(n). Depois de excluir um snapshot, não é possível recuperá-lo.

Marcar um resumo como valor de referência de desempenho

Para marcar todos os snapshots com IDs entre 1 e 3, por exemplo, como uma linha de base de desempenho do sistema, execute
SELECT perfsnap.make_baseline(1, 3).

Limpar valores de referência de desempenho

Para limpar todas as linhas de base com IDs entre 1 e 3, por exemplo, execute SELECT perfsnap.clear_baseline(1, 3).

Otimizar a performance do banco de dados usando os resultados do relatório de resumo

Siga estas etapas para otimizar o desempenho do banco de dados do AlloyDB:

  1. Crie snapshots de referência quando o banco de dados estiver ocioso ou com uma carga média.
  2. Inicie a carga de trabalho ou consulta cuja performance você quer melhorar.
  3. Quando a carga de trabalho ou 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.
  4. Compare os relatórios que você criou com os dois conjuntos de snapshots e identifique as mudanças que podem melhorar a performance. Para mais informações sobre as 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 resumo de desempenho e as melhorias recomendadas para cada seção. Para mais informações sobre as seções do relatório de snapshot de performance e os 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 momento em que a máquina está ativa. N/A
ID do snapshot Lista o ID e o ponto no tempo dos snapshots usados para criar este relatório. N/A
Insights do Sistema CPU do host Detalhes do uso da CPU do host. Se a utilização da CPU for maior que 80%, recomendamos mudar para um sistema com mais vCPUs.
Memória do host Detalhes da utilização da memória do host. Se a memória disponível for menor que 15%, recomendamos que você aumente até o próximo tamanho disponível.
Carregar perfil Lista contadores que ajudam a caracterizar sua carga de trabalho em termos de geração de registro de escrita antecipada (WAL, na sigla em inglês), requisitos de E/S e gerenciamento de conexão. Se as leituras físicas forem maiores que as leituras lógicas, considere aumentar até o próximo tamanho disponível para oferecer suporte a um armazenamento em cache maior de dados.
Detalhes sobre o tempo de resposta e a classe de espera Desmembramento do tempo que os processos do Postgres gastaram durante a execução da carga de trabalho. Concentre o ajuste para encurtar a 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 sobre a carga de trabalho por banco de dados Principais métricas de cada banco de dados, incluindo confirmações, reversão, taxa de acerto e informações sobre tabelas temporárias e operações de classificação. Se as revisões forem altas, considere diagnosticar o app.
Informações sobre 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. Localize problemas no aplicativo se houver um deadlock.
Informações sobre o dimensionamento do banco de dados
Mostra 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 vácuo Informações sobre o vácuo Detalhes de E/S e contadores para operações de vácuo. Por padrão, o AlloyDB realiza a aspiração adaptativa. É possível substituir algumas das configurações de vácuo para se adequar à carga de trabalho. Por exemplo, reduzir operações de aspiração se muita E/S for gasta nessas solicitações.
Informações sobre o vácuo por banco de dados Mostra as seguintes informações:
  • Idade atual de datfrozenxid (XIDs descongelados mais antigos) de cada banco de dados ou o número de transações de datfrozenxid para o XID da transação atual.
  • IDs de transação descongelados consumidos de todos os IDs de transação.
  • Resultado de autovacuum_freeze_max_age - age(pg_database.datfrozenxid), que indica os intervalos de idade aproximados (em transações) no segundo horário de snapshot, quando o autovacuum é acionado para evitar o wraparound em um nível agregado de banco de dados.
Se a idade do campo "Frozen XID" for muito antiga ou se a porcentagem de transações consumidas estiver próxima de 90%, considere fazer a limpeza. Se a diferença de vácuo agregado diminuir, isso indica que um vácuo será aplicado pelo Postgres para evitar o wraparound.
Detalhes de espera dos processos do banco de dados Informações detalhadas sobre o back-end e os processos em segundo plano de
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 a espera no WALWrite, por exemplo, aumente o número de wal_buffers disponível 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 resumo de desempenho por padrão. A lista contém o histograma de eventos de espera para processos de back-end e 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 intervalo de tempo de espera maior. Talvez haja um problema com muitos eventos de espera ou com cada tempo de espera consumido.
Estatísticas variadas Estatísticas do registro de gravação antecipada (WAL) Resumo das estatísticas do WAL. Se você tiver muito tempo de sincronização, ajuste as flags de banco de dados relacionadas (GUC) para melhorar a 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 do 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 recomendados.

Limitações

  • Para evitar o aumento de espaço, é possível criar manualmente no máximo 2.500 snapshots em uma instância. O inchaço 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 fazer um novo.

  • O AlloyDB Omni limpa periodicamente snapshots manuais com mais de 90 dias.

A seguir