Gerenciar bancos de dados não é uma tarefa fácil e pode ser facilmente frustrante sem saber o que está acontecendo nos bastidores. Seja tentando descobrir se novos índices são úteis, a contagem de transações em um banco de dados em um determinado momento ou quem está conectado ao banco de dados em um determinado momento, os dados que permitem que os administradores realmente saibam o desempenho de seus bancos de dados são importantes. Felizmente, com o PostgreSQL, esses dados para tudo isso estão disponíveis no catálogo do sistema PostgreSQL.
O Catálogo do Sistema PostgreSQL é um esquema com tabelas e visualizações que contêm metadados sobre todos os outros objetos dentro do banco de dados e muito mais. Com ele, podemos descobrir quando várias operações acontecem, como tabelas ou índices são acessados e até mesmo se o sistema de banco de dados está ou não lendo informações da memória ou precisando buscar dados do disco.
Aqui, veremos uma visão geral do catálogo do sistema e destacaremos como lê-lo e como extrair informações úteis dele. Alguns dos metadados são diretos e outras partes exigem um pouco de digestão para gerar informações realmente úteis. De qualquer forma, o PostgreSQL nos dá uma ótima plataforma para construir qualquer informação que precisemos sobre o próprio banco de dados.
O Catálogo PostgreSQL
O PostgreSQL armazena as informações de metadados sobre o banco de dados e o cluster no esquema ‘pg_catalog’. Essas informações são parcialmente usadas pelo próprio PostgreSQL para acompanhar as coisas em si, mas também são apresentadas para que pessoas/processos externos também possam entender o interior dos bancos de dados.
O Catálogo PostgreSQL tem uma regra bastante sólida:olhe, não toque. Embora o PostgreSQL armazene todas essas informações em tabelas como qualquer outro aplicativo faria, os dados nas tabelas são totalmente gerenciados pelo próprio PostgreSQL e não devem ser modificados a menos que seja uma emergência absoluta, e mesmo assim é provável que uma reconstrução seja feita posteriormente.
Veremos algumas tabelas de catálogo úteis, como ler os dados e coisas inteligentes que podemos fazer com os próprios dados. Existem algumas tabelas no catálogo que não iremos ver, mas todas as informações para essas várias tabelas podem ser encontradas na documentação oficial do PostgreSQL.
Metadados de todo o sistema
Uma boa parte das tabelas que podemos consultar no catálogo são tabelas de 'todo o sistema', onde não importa a qual banco de dados estamos conectados, os dados representam todo o cluster, nenhum banco de dados único.
Informações do banco de dados
As informações gerais do banco de dados são armazenadas em pg_database e as estatísticas são armazenadas em pg_stat_database.
pg_database:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |A tabela pg_database contém uma linha para cada banco de dados no cluster, incluindo os três que saem da caixa (postgres, template0 e template1). Esta linha contém informações para codificação, limite de conexão e outros metadados básicos.
Colunas de interesse:
oid - O identificador de objeto, que não aparece em uma saída de consulta, a menos que seja referenciado diretamente. Este número corresponderá a um diretório no diretório de dados do cluster
datname - O nome do banco de dados.
datdba - O proprietário do banco de dados, oid referencia pg_authid .oid.
encoding - A codificação de caracteres para este banco de dados, pg_encoding_to_char() irá converter para um nome legível.
datconnlimit - O número máximo de conexões simultâneas permitidas no banco de dados.
dattablespace - O tablespace padrão para este banco de dados, referencia pg_tablespace.oid.
pg_stat_database:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Esta tabela de estatísticas é onde obtemos dados interessantes e úteis. Cada linha nesta tabela contém dados ao vivo para cada banco de dados e pode ser exportada periodicamente para ser rastreada ao longo do tempo se desejar monitorar as alterações.
Transações
As informações da transação podem ser encontradas nas colunas xact_commit e xact_rollback, que contêm o número de transações que o banco de dados confirmou e retrocedeu, respectivamente. Isso ajudará a mostrar o quão ativo é um banco de dados, bem como identificar possíveis falhas com programas que podem estar cometendo erros / retrocedendo em uma taxa alarmante.
Acesso ao disco e à memória
As informações sobre se os dados são ou não recuperados do disco ou da memória são armazenadas nas colunas blks_read e blks_hit. Blks_read mostra o número de blocos que este banco de dados leu do disco, enquanto blks_hit mostra o número de blocos que foram encontrados no buffer cache do PostgreSQL (representado pelo parâmetro shared_buffers). Como a RAM é muito mais rápida que o disco, idealmente veríamos blks_hit consistentemente mais alto que blks_read e, caso contrário, podemos reavaliar nossa memória disponível.
Tuplas
As próximas colunas lidam com tuplas. Tup_returned é o número de linhas retornadas no banco de dados, que é o número de linhas lidas por varreduras sequenciais se de uma tabela, ou o número de entradas de índice retornadas quando de um índice”. Tup_fetched é o número de linhas buscadas no banco de dados, o que significa que elas foram resultado de varreduras de bitmap, que é o número de linhas de tabela buscadas por varreduras de bitmap se de uma tabela, ou linhas de tabela buscadas por varreduras de índice simples se estiver usando um índice.
Também temos tup_inserted, tup_updated e tup_deleted, que representam o número de tuplas inseridas, atualizadas e excluídas neste banco de dados, respectivamente. Isso ajudará a entender como os dados entram, mudam e saem do banco de dados. Como as tuplas atualizadas e excluídas resultam em linhas mortas, valores altos nessas colunas sugerem que as operações de autovacuum sejam ajustadas para atender às necessidades da atividade do banco de dados.
Conflitos
Se o banco de dados em questão for um servidor em espera, os conflitos de coluna são úteis como uma maneira de rastrear quantas consultas foram canceladas devido a conflitos com o modo de espera em 'modo de recuperação'. Se não for um cluster em espera, essa coluna poderá ser ignorada.
Arquivos/dados temporários
Às vezes, as consultas precisarão ser gravadas em arquivos temporários. Isso pode acontecer quando a quantidade de work_mem alocada para a conexão estiver esgotada e precisar continuar uma operação de classificação no disco em vez de na memória. A coluna temp_files rastreia o número desses arquivos que foram criados e temp_bytes rastreia o tamanho total de todos os arquivos temporários usados. Esses dados podem ajudar a informar o ajuste de work_mem ou até mesmo encontrar consultas que podem usar a reescrita se o tamanho do arquivo temporário for muito grande.
Impasses
A coluna de deadlocks rastreia quantas vezes ocorre um deadlock. Uma vez que um impasse pode causar erros para consultas que, de outra forma, não causariam erros, é bom acompanhar isso e garantir que os aplicativos não estejam pisando nos pés uns dos outros.
Tempos de leitura e gravação
As colunas blk_read_time e blk_write_time rastreiam o número total de milissegundos que os back-ends no banco de dados gastam lendo e gravando dados, o que pode ser útil ao tentar comparar/melhorar a velocidade de leitura/gravação do disco
Redefinição de estatísticas
Esta coluna, stats_reset, simplesmente mostra um timestamp (com fuso horário) da última vez que as estatísticas mencionadas nesta linha foram redefinidas. Um valor nulo significa que eles não foram redefinidos desde o início, ou até mesmo uma falha no banco de dados que pode ter eliminado essas estatísticas.
Pontos de verificação e o escritor em segundo plano
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00O cluster PostgtreSQL gerencia a gravação de dados em disco de várias maneiras diferentes. Em termos de 'buffers sujos' (dados na memória que foram alterados desde a leitura do disco, mas ainda não tiveram essa alteração gravada no disco), isso é feito por um ponto de verificação ou pelo gravador em segundo plano. Como um buffer sujo deve ser gravado no disco antes de ser liberado ou realocado, é crucial garantir que esses processos sejam ajustados com precisão, e esta tabela ajuda a esclarecer como tudo está funcionando.
Pontos de verificação
Um ponto de verificação acontece no agendamento (representado pelo parâmetro checkpoint_timeout) ou quando a quantidade máxima de arquivos WAL foi usada desde o último ponto de verificação e precisa forçar um ponto de verificação. De qualquer forma, um ponto de verificação grava buffers sujos no disco e há quatro colunas rastreando-o.
As colunas checkpoints_timed e checkpoints_req mostram o número de checkpoints agendados que ocorrem (temporizados) e o número de checkpoints solicitados (também chamados de forçados). Um alto valor de escalada de checkpoint_req pode sugerir um valor de max_wal_size insuficiente.
As colunas checkpoint_write_time e checkpoint_sync_time registram a quantidade total de tempo (em milissegundos) que o processo do ponto de verificação gastou gravando e sincronizando no disco.
Por fim, buffers_checkpoint é o número total de buffers gravados no disco por pontos de verificação.
Escritor em segundo plano
O gravador em segundo plano é um processo separado que grava buffers sujos no disco, o que reduz a quantidade de trabalho que o checkpointer precisa fazer.
A coluna buffers_clean representa o número de buffers gravados no disco pelo processo em segundo plano. Quando comparado com buffers_checkpoint, ele mostra quanto da carga de trabalho é tratada por cada processo (com o conhecimento adicional de que o gravador em segundo plano tem a possibilidade de gravar buffers várias vezes se eles mudarem com frequência, versus menos frequentemente com um ponto de verificação cronometrado).
Maxwritten_clean representa o número de vezes que o gravador em segundo plano atingiu o número máximo de páginas para liberar cada vez que é executado (controlado com o parâmetro bgwriter_lru_maxpages).
Buffers em geral
As colunas restantes nos mostram as informações gerais do buffer, com buffers_backend sendo o número de buffers que um backend teve que escrever, em vez de gravador ou checkpointer em segundo plano, buffers_backend_fsync é uma contagem de quantas vezes um backend teve que executar sua própria chamada fsync e buffers_alloc mostra o número de buffers que foram alocados em geral.
Atividade do banco de dados e bloqueios
Existem duas visualizações que mostram a atividade atual do usuário, pg_stat_activity e pg_locks. Quando consultados, eles mostram informações sobre as conexões atuais com os bancos de dados e que tipo de bloqueios eles têm em quais relações.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendInformações gerais
A visualização pg_stat_activity mostra uma linha para cada conexão com o banco de dados e algumas informações básicas sobre ela. A coluna datname representa o banco de dados ao qual a conexão está realmente conectada, pid é o ID do processo da conexão no próprio host do banco de dados e usesysid e usename representam o usuário do banco de dados conectado.
Para a fonte do cliente, client_addr é o endereço IP do host de onde a conexão veio, null significa que é uma conexão de soquete unix local.
Carimbos de data e hora
Existem quatro colunas de timestamp que mostram quando certas coisas começaram:backend_start é quando a conexão foi realmente estabelecida, xact_start é quando a transação atual foi iniciada (null se o cliente não tiver uma transação aberta), query_start é quando a consulta atual ou mais recente foi iniciada, e state_change é a hora em que o estado da conexão foi alterado pela última vez.
Status da conexão
Os bits finais de pg_stat_activity cobrem o status real da conexão. Se a consulta estiver aguardando outra para liberar bloqueios, wait_event_type contém algumas informações sobre que tipo de evento de espera é, e a coluna wait_event mostrará o nome do evento de espera. É uma lista longa, mas mais informações podem ser encontradas na documentação do PostgreSQL.
Por fim, a coluna ‘state’ mostra em que estado a conexão atual está, como ativa, ociosa, ociosa na transação, e a coluna de consulta mostrará a consulta real que está sendo executada ou executada mais recentemente.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tA tabela pg_locks trabalha lado a lado com pg_stat_activity se estiver examinando a atividade de consulta. Sempre que um bloqueio é feito em uma relação, essa informação é armazenada em pg_locks. Usando o pid de pg_stat_activity, podemos consultar pg_locks para ver em quais relações uma conexão pode ter bloqueios, que tipos de bloqueios são esses e se os bloqueios foram concedidos ou não.
As colunas mais importantes são 'pid', que corresponde ao pid de pg_stat_activity, 'relation' que corresponde ao OID de pg_class, 'mode' mostrando o nome do modo de bloqueio mantido e 'concedido' que indica se o bloqueio está ou não questão foi concedida.
Informações de replicação
Como o PostgreSQL possui recursos de replicação integrados, existem algumas visualizações que esclarecem o desempenho e o status da própria replicação.
Visualizar pg_stat_replication: contém uma linha para cada processo do remetente WAL, contendo informações sobre seu estado, a localização dos arquivos WAL em que está trabalhando e as informações de conexão do host em espera que está recebendo os dados WAL para replicação.
Visualizar pg_stat_wal_receiver: Se o cluster estiver em espera, ele conterá uma única linha mostrando estatísticas sobre o processo receptor do host.
Visualizar pg_stat_subscription: Se estiver enviando dados WAL para um nó em espera, cada linha aqui representará essa assinatura e conterá informações sobre o status das assinaturas.
Visualizar pg_replication_slots: Contém uma lista de todos os slots de replicação que existem no cluster e seu estado atual.
Metadados específicos do banco de dados
Dentro de cada banco de dados há uma coleção de tabelas de catálogos que possuem informações específicas do banco de dados que está sendo consultado. Se estivermos procurando dados específicos dessas tabelas, devemos nos certificar de que estamos conectados ao banco de dados correto enquanto emitimos as consultas.
É aqui que entra o coração da análise de dados, onde podemos ver exatamente como nossos dados de usuário estão sendo acessados. De tabelas, índices, sequências, as consultas que entram no banco de dados e buscam ou modificam dados, suas ações e impactos serão armazenados nessas tabelas, e podemos analisar essas informações para tomar decisões informadas sobre o gerenciamento do banco de dados estrada.
Metadados de tabela
Os metadados sobre nossas tabelas de usuário são armazenados nas duas tabelas a seguir, e cada uma delas possui uma linha para cada tabela de usuário criada no sistema. A tabela pg_stat_user_tables contém estatísticas sobre o acesso do usuário à tabela, enquanto pg_statio_user_tables contém estatísticas de E/S para cada tabela.
NOTA:Os dados aqui nem sempre são 100% perfeitos e dependem de análises frequentes das tabelas para serem corretos. Autoanalyze cobre isso, mas um bom ajuste do processo de autoanalyze para que ele possa manter boas estatísticas sobre cada tabela. Se as estatísticas parecerem desativadas, executar um ANALYZE manualmente na tabela as atualizará.
Tabela pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0Para nossas estatísticas da tabela de usuários, temos alguns dados.
Métodos de acesso à tabela
Quando os clientes acessam os dados da tabela, eles o fazem diretamente ou por meio de índices. A coluna ‘seq_scan’ conta o número de varreduras sequenciais que a tabela recebeu e ‘seq_tup_read’ conta o número de tuplas lidas por esse processo. A coluna ‘idx_scan’ conta quantas vezes um índice na tabela foi usado para buscar dados.
Atividade de Tupla de Mesa
Agora temos um punhado de colunas que contam diferentes atividades na tabela.
‘n_tup_ins’ rastreia o número de tuplas inseridas
‘n_tup_upd’ rastreia o número de tuplas atualizadas
‘n_tup_del’ rastreia o número de tuplas excluídas
Estado da Tupla da Tabela
Devido a atualizações e exclusões, pode haver tuplas mortas que não são mais dados ativos, e o processo de vácuo eventualmente as liberará. As colunas ‘n_tup_ins’ e ‘n_tup_ins’ rastreiam o número de tuplas que estão vivas e mortas, respectivamente. Quando as tuplas mortas atingem um certo ponto, um autovacuum será lançado, dependendo das configurações do autovacuum.
Atividade de vácuo de mesa
A manutenção da tabela é feita por meio de VACUUM ou AUTOVACUUM e as estatísticas são reunidas por meio de ANALYZE ou AUTOANALYZE. As próximas quatro colunas contêm as datas de quando cada uma dessas operações foi executada pela última vez:‘last_vacuum’, ‘last_autovacuum’, ‘last_analyze’, ‘last_autoanalyze’.
Também temos quatro colunas mais convenientes que simplesmente contam quantas vezes as ações anteriores ocorrem. Usando isso, podemos ver quais tabelas obtêm mais atividade:‘vacuum_count’, ‘autovacuum_count’, ‘analyze_count’ e ‘autoanalyze_count’.
Tabela pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0A saída de E/S é útil para ajudar a entender como os dados estão sendo acessados nos bastidores. A coluna ‘heap_blks_read’ representa o número de blocos de disco lidos para esta tabela e ‘heap_blks_hit’ representa os blocos de buffer lidos da memória nesta tabela. Isso é útil para saber se as consultas que acessam a tabela constantemente precisam ir para o disco ou buscar os dados da memória.
As estatísticas de índice na tabela mostram as mesmas informações com as colunas ‘idx_blks_read’ e ‘idx_blks_hit’.
Por fim, se a tabela tiver tabelas TOAST, as colunas 'toast_blks_hit' e 'toast_blks_read' rastreiam tabelas toast, enquanto 'tdix_blks_read' e 'tdix_blks_read' rastreiam os índices nessas tabelas toast.
Metadados de índice
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Assim como as contrapartes da tabela, esta tabela contém informações especificamente sobre os índices. Uma linha por índice, esta tabela mostra quantas vezes o índice foi verificado com a coluna ‘idx_scan’, quantas tuplas foram lidas com ‘idx_tup_read’ e quantas linhas ativas foram realmente buscadas com ‘idx_tup_fetch’.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380Para pg_statio_user_indexes, as duas colunas disponíveis para dados são ‘idx_blks_read’ e ‘idx_blks_hit’, representando o número de blocos lidos do disco e da memória.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
O que podemos fazer com esses dados?
Seja criativo! Se as consultas a uma tabela específica parecerem extremamente lentas, rastreie sua atividade ao longo do tempo, veja quantas varreduras sequenciais ela recebe versus varreduras de índice, veja se está indo para o disco ou memória para os dados.
Se uma tabela grande continua sendo autovacuumed com frequência, rastreie as tuplas vivas para mortas ao longo do tempo, talvez ela precise especificamente que o autovacuum seja ajustado para que possa ser concluído mais rapidamente, ou talvez a tabela seja candidata a particionamento.
Como podemos ver quando os dados vêm do disco ou da memória, podemos criar uma proporção de memória para disco ao longo do tempo, identificando se a qualquer momento a proporção cai ao longo do dia.
A quantidade de tabelas que cobrimos passou pelos grandes rebatedores, os principais dados que são úteis para conhecer o funcionamento interno dos bancos de dados. No entanto, há muito mais tabelas no catálogo do sistema que contêm dados úteis para a situação. Ler outras tabelas como antes ajudará a fornecer insights sobre a integridade do banco de dados em geral.
Para obter mais informações sobre quaisquer tabelas ou visualizações no Catálogo PostgreSQL, visite a documentação oficial aqui, bem como informações sobre o coletor de estatísticas aqui.
