PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Principais coisas para monitorar no PostgreSQL - Analisando sua carga de trabalho

Principais itens a serem monitorados no PostgreSQL - Analisando sua carga de trabalho


Em sistemas informatizados, monitoramento é o processo de coletar métricas, analisar, computar estatísticas e gerar resumos e gráficos sobre o desempenho ou a capacidade de um sistema, além de gerar alertas em caso de problemas ou falhas inesperadas que exijam atenção ou ação imediata. Portanto, o monitoramento tem dois usos:um para análise e apresentação de dados históricos que nos ajudam a identificar tendências de médio e longo prazo em nosso sistema e, assim, nos ajudam a planejar atualizações, e um segundo para ação imediata em caso de problemas.

O monitoramento nos ajuda a identificar problemas e reagir a esses problemas em uma ampla gama de campos, como:
  • Infraestrutura/Hardware (físico ou virtual)
  • Rede
  • Armazenamento
  • Software do sistema
  • Software de aplicativo
  • Segurança

O monitoramento é uma parte importante do trabalho de um DBA. O PostgreSQL, tradicionalmente, é conhecido por ser de “baixa manutenção” graças ao seu design sofisticado e isso significa que o sistema pode conviver com baixo atendimento quando comparado a outras alternativas. No entanto, para instalações sérias onde alta disponibilidade e desempenho são de importância fundamental, o sistema de banco de dados deve ser monitorado regularmente.

O papel do DBA PostgreSQL pode atingir níveis superiores dentro da hierarquia da empresa além do estritamente técnico:além de monitoramento básico e análise de desempenho,  deve ser capaz de detectar mudanças nos padrões de uso, identificar as possíveis causas, verificar as suposições e, finalmente, traduzir as descobertas em termos de negócios. Como exemplo, o DBA deve ser capaz de identificar alguma mudança repentina em uma determinada atividade que possa estar vinculada a uma possível ameaça à segurança. Assim, o papel do DBA do PostgreSQL é um papel fundamental dentro da empresa, e deve trabalhar em estreita colaboração com outros chefes de departamento para identificar e resolver os problemas que surgem. O monitoramento é uma grande parte dessa responsabilidade.

O PostgreSQL fornece muitas ferramentas prontas para uso para nos ajudar a coletar e analisar dados. Além disso, devido à sua extensibilidade, fornece os meios para desenvolver novos módulos no sistema central.

O PostgreSQL é altamente dependente do sistema (hardware e software) em que é executado. Não podemos esperar que um servidor PostgreSQL tenha um bom desempenho se houver problemas em qualquer um dos componentes vitais do resto do sistema. Portanto, a função do DBA do PostgreSQL se sobrepõe à função do administrador do sistema. Abaixo, ao examinarmos o que observar no monitoramento do PostgreSQL, encontraremos variáveis ​​e métricas dependentes do sistema, bem como números específicos do PostgreSQL.

O monitoramento não vem de graça. Um bom investimento deve ser feito pela empresa/organização com o compromisso de gerenciar e manter todo o processo de monitoramento. Ele também adiciona uma pequena carga no servidor PostgreSQL. Isso é pouco para se preocupar se tudo estiver configurado corretamente, mas devemos ter em mente que essa pode ser outra maneira de usar mal o sistema.

Noções básicas de monitoramento do sistema


Variáveis ​​importantes no monitoramento do sistema são:
  • Uso da CPU
  • Uso da rede
  • Espaço em disco/utilização em disco
  • Uso de RAM
  • IOPS de disco
  • Trocar o uso do espaço
  • Erros de rede

Aqui está um exemplo de ClusterControl mostrando gráficos para algumas variáveis ​​críticas do PostgreSQL provenientes de pg_stat_database e pg_stat_bgwriter (que abordaremos nos parágrafos a seguir) enquanto executamos pgbench -c 64 -t 1000 pgbench duas vezes:

Notamos que temos um pico na leitura de blocos na primeira execução, mas chegamos perto de zero durante a segunda execução, pois todos os blocos são encontrados em shared_buffers.

Outras variáveis ​​de interesse são atividade de paging, interrupções, trocas de contexto, entre outras. Há uma infinidade de ferramentas para usar em Linux/BSDs e sistemas unix ou semelhantes a unix. Alguns deles são:

  • ps:para uma lista dos processos em execução

  • top/htop/syst:para monitoramento da utilização do sistema (CPU/memória)

  • vmstat:para monitoramento geral da atividade do sistema (incluindo memória virtual)

  • iostat/iotop/top -mio:para monitoramento de IO

  • ntop:para monitoramento de rede

Aqui está um exemplo de vmstat em uma caixa do FreeBSD durante uma consulta que requer algumas leituras de disco e também alguns cálculos:
procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

Repetindo a consulta, não notamos nenhuma nova explosão na atividade do disco, pois esses blocos de disco já estariam no cache do SO. Embora o DBA do PostgreSQL deva ser capaz de entender completamente o que está acontecendo na infraestrutura subjacente em que o banco de dados é executado, o monitoramento de sistema mais complexo geralmente é um trabalho para o administrador do sistema, pois esse é um tópico grande em si.

No linux, um atalho muito útil para o top utilitário está pressionando “C”, que alterna mostrando a linha de comando dos processos. O PostgreSQL por padrão reescreve a linha de comando dos backends com a atividade SQL real que eles estão executando no momento e também com o usuário.

Noções básicas de monitoramento PostgreSQL


Variáveis ​​importantes no monitoramento do PostgreSQL são:
  • Desempenho do cache do buffer (acessos de cache versus leituras de disco)
  • Número de confirmações
  • Número de conexões
  • Número de sessões
  • Pontos de verificação e estatísticas do bgwriter
  • Aspiradores
  • Bloqueios
  • Replicação
  • E por último, mas não menos importante, as consultas

Geralmente, há duas maneiras em uma configuração de monitoramento para realizar a coleta de dados:
  • Para adquirir dados por meio de um log
  • Para adquirir dados consultando o sistema PostgreSQL

A aquisição de dados baseada em arquivo de log depende do log do PostgreSQL (configurado adequadamente). Podemos usar esse tipo de registro para processamento “off-line” dos dados. O monitoramento baseado em arquivo de log é mais adequado quando uma sobrecarga mínima para o servidor PostgreSQL é necessária e quando não nos importamos com dados ao vivo ou em obter alertas ao vivo (embora o monitoramento ao vivo usando dados de arquivo de log possa ser possível, por exemplo, direcionando o log do postgresql para o syslog e, em seguida, transmitir o syslog para outro servidor dedicado para processamento de log).
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

Coletor de estatísticas do PostgreSQL


O PostgreSQL fornece um rico conjunto de visualizações e funções prontamente disponíveis através do subsistema Statistics Collector. Novamente, esses dados são divididos em duas categorias:
  • Informações dinâmicas sobre o que o sistema está fazendo no momento.
  • Estatísticas acumuladas desde que o subsistema do coletor de estatísticas foi redefinido pela última vez.

Visualizações de estatísticas dinâmicas fornecer informações sobre a atividade atual por processo (pg_stat_activity), status de replicação física (pg_stat_replication), status de espera física (pg_stat_wal_receiver) ou lógica (pg_stat_subscription), ssl (pg_stat_ssl) e vácuo (pg_stat_progress_vacuum).

Visualizações de estatísticas coletadas fornecem informações sobre processos importantes em segundo plano, como o arquivador wal, o bgwriter e objetos de banco de dados:tabelas de usuário ou sistema, índices, sequências e funções, bem como os próprios bancos de dados.

Deve ser bastante óbvio agora que existem várias maneiras de categorizar dados relacionados ao monitoramento:
  • Por fonte:
    • Ferramentas do sistema (ps, top, iotop, etc)
    • Arquivo de log PgSQL
    • Banco de dados
      • Dinâmico
      • Recolhido
  • Por operação específica do banco de dados:
    • Cache de buffer
    • Compromissos
    • Consultas
    • Sessões
    • Pontos de verificação
    • etc

Depois de ler este artigo e experimentar as noções, conceitos e termos apresentados, você deverá ser capaz de fazer uma matriz 2D com todas as combinações possíveis. Como exemplo, a atividade específica do PostgreSQL (comando SQL) pode ser encontrada usando:ps ou top (utilitários do sistema), os arquivos de log do PostgreSQL, pg_stat_activity (visualização dinâmica), mas também usando pg_stat_statements uma extensão encontrada em contrib (visualização de estatísticas coletadas) . Da mesma forma, informações sobre bloqueios podem ser encontradas nos arquivos de log do PostgreSQL, pg_locks e pg_stat_activity (apresentado logo abaixo) usando wait_event e wait_event_type . Por isso, é difícil cobrir a vasta área de monitoramento de forma linear unidimensional, e o autor corre o risco de confundir o leitor por causa disso. Para evitar isso, abordaremos o monitoramento seguindo o curso da documentação oficial e adicionando informações relacionadas conforme necessário.

Visualizações de Estatísticas Dinâmicas


Usando pg_stat_activity podemos ver qual é a atividade atual pelos vários processos de back-end. Por exemplo, se executarmos a seguinte consulta em partes da tabela com cerca de 3 milhões de linhas:
testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

E vamos executar a seguinte consulta, que precisa de alguns segundos para ser concluída:
testdb=# select avg(age(date_added)) FROM parts;

Ao abrir um novo terminal e executar a seguinte consulta, enquanto a anterior ainda está em execução, obtemos:
testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

A visualização pg_stat_activity nos fornece informações sobre o processo de backend, o usuário, o cliente, a transação, a consulta, o estado, bem como informações abrangentes sobre o status de espera da consulta.

Mas por que 3 linhas? Nas versões>=9.6, se uma consulta puder ser executada em paralelo ou partes dela puderem ser executadas em paralelo, e o otimizador achar que a execução paralela é a estratégia mais rápida, ele criará um Gather ou Reunir mesclagem node e, em seguida, solicita no máximo max_parallel_workers_per_gather processos de trabalho em segundo plano, que por padrão é 2, daí as 3 linhas que vemos na saída acima. Podemos diferenciar o processo de back-end do cliente do trabalhador em segundo plano usando o backend_type coluna. Para que a visualização pg_stat_activity seja habilitada, você deverá certificar-se de que o parâmetro de configuração do sistema track_activities está ligado. O pg_stat_activity fornece informações ricas para determinar consultas bloqueadas pelo uso das colunas wait_event_type e wait_event.

Uma maneira mais refinada de monitorar declarações é por meio das pg_stat_statements contrib, mencionada anteriormente. Em um sistema Linux recente (Ubuntu 17.10, PostgreSQL 9.6), isso pode ser instalado com bastante facilidade:
testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Vamos criar uma tabela com 100.000 linhas, e então resetar pg_stat_statements, reiniciar o servidor PostgreSQL, realizar um select nesta tabela no sistema (ainda frio), e então ver o conteúdo de pg_stat_statements para o select:
testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Agora vamos realizar o select * mais uma vez e então olhar novamente no conteúdo de pg_stat_statements para esta consulta:
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Então, na segunda vez que a instrução select encontra todos os blocos necessários nos buffers compartilhados do PostgreSQL, e pg_stat_statements relata isso via shared_blks_hit . pg_stat_statements fornece informações sobre o número total de chamadas de uma instrução, o total_time, min_time, max_time e mean_time, que podem ser extremamente úteis ao tentar analisar a carga de trabalho do seu sistema. Uma consulta lenta que é executada com muita frequência deve exigir atenção imediata. Da mesma forma, taxas de acerto consistentemente baixas podem significar a necessidade de revisar os shared_buffers contexto.

pg_stat_replication fornece informações sobre o status atual da replicação para cada wal_sender. Vamos supor que configuramos uma topologia de replicação simples com nosso primário e um hot standby, então podemos consultar pg_stat_replication no primário (fazer o mesmo no standby não produzirá resultados, a menos que tenhamos configurado a replicação em cascata e este standby específico serve como um upstream para outros standbys downstream) para ver o status atual da replicação:
testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

As 4 colunas sent_lsn , write_lsn , flush_lsn , replay_lsn informe-nos a posição exata do WAL em cada estágio do processo de replicação no modo de espera remoto. Em seguida, criamos um tráfego pesado no primário com um comando como:
testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

E veja pg_stat_replication novamente:
postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Agora vemos que temos um atraso entre o primário e o de espera descrito no sent_lsn , write_lsn , flush_lsn , replay_lsn valores. Desde o PgSQL 10.0, o pg_stat_replication também mostra o atraso entre um WAL recentemente liberado localmente e o tempo que levou para ser escrito, liberado e reproduzido remotamente, respectivamente. Ver nulos nessas 3 colunas significa que o primário e o standby estão em sincronia.

O equivalente a pg_stat_replication no lado de espera é chamado:pg_stat_wal_receiver: 
testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Quando não há atividade e o modo de espera reproduziu tudo, latest_end_lsn deve ser igual a sent_lsn no primário (e em todos os números de seqüência de log intermediários).

Da mesma forma que a replicação física, no caso da replicação lógica, onde o papel do primário é assumido pelo publicador e o papel do standby pelo assinante, naturalmente o papel de pg_stat_wal_receiver é usado por pg_stat_subscription . Podemos consultar pg_stat_subscription do seguinte modo:
testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

Observe que, do lado do editor, a visualização correspondente é a mesma do caso de replicação física:pg_stat_replication .

Visualizações de estatísticas coletadas


pg_stat_archiver view tem uma linha que fornece informações sobre o arquivador wal. Manter um instantâneo dessa linha em intervalos regulares permite calcular o tamanho do tráfego WAL entre esses intervalos. Também fornece informações sobre falhas durante o arquivamento de arquivos WAL.

pg_stat_bgwriter view fornece informações muito importantes sobre o comportamento de:
  • O ponto de verificação
  • O escritor de plano de fundo
  • Os back-ends (de atendimento ao cliente)

Dado que esta vista dá dados cumulativos desde a última reposição Émuitoútil criar outra tabela com carimbo de data/hora com instantâneos periódicos do pg_stat_bgwriter , para que seja fácil obter uma perspectiva incremental entre dois instantâneos. O ajuste é uma ciência (ou mágica) e requer registro e monitoramento extensivos, bem como uma compreensão clara dos conceitos subjacentes e internos do PostgreSQL para obter bons resultados, e essa visão é por onde começar, procurando coisas como:
  • Os checkpoints_timed a grande maioria dos checkpoints totais? Caso contrário, as ações devem ser tomadas, os resultados medidos e iterar todo o processo até que nenhuma melhoria seja encontrada.
  • São os buffers_checkpoint uma boa maioria sobre os outros dois tipos (buffers_clean mas o mais importante buffers_backend ) ? Se buffers_backend forem altos, novamente, certos parâmetros de configuração devem ser alterados, novas medições devem ser feitas e reavaliadas.

Pg_stat_[user|sys|all]_tables


O uso mais básico dessas visualizações é verificar se nossa estratégia de vácuo funciona conforme o esperado. Grandes valores de tuplas mortas em relação a tuplas vivas significam uma aspiração ineficiente. Essas visualizações também fornecem informações sobre varreduras e buscas seq vs index, informações sobre o número de linhas inseridas, atualizadas, excluídas, bem como atualizações HOT. Você deve tentar manter o número de atualizações HOT o mais alto possível para melhorar o desempenho.

Pg_stat_[user|sys|all]_indexes


Aqui o sistema armazena e mostra informações sobre o uso de índice individual. Uma coisa a ter em mente é que idx_tup_read é mais preciso que idx_tup_fetch. Índices não PK/não exclusivos com baixo idx_scan devem ser considerados para remoção, uma vez que apenas dificultam as atualizações HOT. Como mencionado no blog anterior, a indexação excessiva deve ser evitada, a indexação tem um custo.

Pg_statio_[user|sys|all]_tables


Nessas visualizações podemos encontrar informações sobre o desempenho do cache em relação a leituras de heap de tabela, leituras de índice e leituras TOAST. Uma consulta simples para contar a porcentagem de ocorrências e a distribuição das ocorrências nas tabelas seria:
with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Isso nos diz que pelo menos 50% das tabelas têm taxas de acerto superiores a 96,93% e 83,5% das tabelas têm uma taxa de acertos superior a 59,4%.

Pg_statio_[user|sys|all]_indexes


Essa exibição contém informações de leitura/acerto de bloco para índices.

Pg_stat_database


Essa exibição contém uma linha por banco de dados. Ele mostra algumas das informações das visualizações anteriores agregadas a todo o banco de dados (blocos lidos, blocos atingidos, informações sobre tups), algumas informações relevantes para todo o banco de dados (total de xactions, arquivos temporários, conflitos, deadclocks, tempo de leitura/gravação) e, finalmente, o número de back-ends atuais.

O que procurar aqui é a proporção de blks_hit/(blks_hit + blks_read) :quanto maior o valor, melhor para a E/S do sistema. No entanto, as falhas não devem necessariamente ser contabilizadas para leituras de disco, pois podem ter sido muito bem atendidas pelo cache de arquivos do sistema operacional.

Da mesma forma que outras visualizações de estatísticas coletadas mencionadas acima, deve-se criar uma versão com carimbo de data/hora do pg_stat_database ver e ter uma visão das diferenças entre dois instantâneos consecutivos:
  • O número de reversões está aumentando?
  • Ou o número de xactions confirmadas?
  • Estamos tendo muito mais conflitos do que ontem (isso se aplica a esperas)?
  • Temos números anormalmente altos de impasses?

Todos esses são dados muito importantes. Os dois primeiros podem significar alguma mudança em algum padrão de uso, que deve ser explicado. O alto número de conflitos pode significar que a replicação precisa de alguns ajustes. O alto número de deadlocks é ruim por muitas razões. Não apenas o desempenho é baixo porque as transações são revertidas, mas também se um aplicativo sofre de deadlocks em uma topologia mestre única, os problemas só serão amplificados se passarmos para multimestre. Nesse caso, o departamento de engenharia de software deve reescrever as partes do código que causam os impasses.

Bloqueios

Recursos relacionados ClusterControl for PostgreSQL Como gerenciar e monitorar seu servidor Postgres existente Como comparar o desempenho do PostgreSQL
Locking é um tópico muito importante no PostgreSQL e merece seu próprio blog(s). No entanto, o monitoramento básico de bloqueios deve ser feito da mesma forma que os outros aspectos do monitoramento apresentados acima. pg_locks A visualização fornece informações em tempo real sobre os bloqueios atuais no sistema. Podemos detectar bloqueios de longa espera definindo log_lock_waits , as informações sobre esperas longas serão registradas no log do PgSQL. Se notarmos um bloqueio alto incomum que resulta em longas esperas, como no caso dos impasses mencionados acima, os engenheiros de software devem revisar quaisquer partes de código que possam causar bloqueios prolongados, por exemplo, bloqueio explícito na aplicação (LOCK TABLE ou SELECT … FOR UPDATE).

Da mesma forma que no caso de deadlocks, um sistema com travas curtas se moverá mais facilmente para uma configuração multi-mestre.