Métricas Sistêmicas do PostgreSQL

Imagina que seu servidor PostgreSQL é um restaurante, e a gente é tipo os fiscais. Pra esse restaurante funcionar de boa, a gente precisa ficar de olho em quantos ingredientes (CPU, memória, disco) estão sendo usados, com que frequência eles acabam e quem tá consumindo tudo isso. Se a gente vacilar, nosso "restaurante" pode aceitar pedidos demais e não dar conta, ou simplesmente cair no meio do expediente. Por isso, entender as métricas sistêmicas é essencial.

Principais métricas pra monitorar no PostgreSQL:

1. CPU: mostra quanto tempo de processador tá sendo gasto pra rodar as queries.
2. Memória (RAM): mostra como o PostgreSQL tá usando a RAM, incluindo cache de queries.
3. Espaço em disco: talvez a mais óbvia: não dá pra salvar mais dados do que o disco permite.

Nosso objetivo é aprender a checar e interpretar as métricas sistêmicas do PostgreSQL pra evitar problemas de performance e falta de recursos.

Monitorando o uso de CPU

O processador é o coração do seu servidor. O PostgreSQL pode consumir CPU tanto pra rodar queries pesadas quanto pra tarefas de fundo, tipo autoanálise e autovacuum. Se seu banco tá parecendo aquele amigo esfomeado que devora CPU sem parar, tá na hora de agir.

1. Usando ferramentas do sistema.
   Pra começar, veja quanto tempo de CPU o PostgreSQL tá usando no sistema. No Linux, você pode usar os comandos top ou htop.

Ache o processo do PostgreSQL (normalmente aparece com o nome do seu banco). Por exemplo, postgres: postgres [your_query].

Fica de olho na coluna %CPU. Se ela tá sempre lá em cima, é sinal de alerta.

2. Analisando a carga de CPU pelo PostgreSQL.

O PostgreSQL tem views internas pra monitorar a carga. A mais útil aqui é a pg_stat_activity, que mostra as queries ativas.

Exemplo de query:

SELECT pid, usename, query, state, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC;

O que importa aqui?

• state = 'active' mostra só as queries que tão rodando agora.
• duration mostra há quanto tempo as queries tão usando CPU.

Dica prática:

Se você ver uma query que tá rodando faz tempo e não deveria, confere se os índices tão sendo usados direito. Também dá pra matar o processo problemático usando pg_terminate_backend.

Exemplo de encerramento:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active' AND duration > interval '10 minutes';

Monitorando o uso de memória

Memória é o segundo recurso mais importante pro PostgreSQL, principalmente quando o assunto é cache de dados. O PostgreSQL usa bastante RAM (via work_mem e shared_buffers) pra acelerar as operações.

1. Principais parâmetros do PostgreSQL pra uso de memória:

• shared_buffers: É o bloco principal de memória reservado pro PostgreSQL. Normalmente ocupa de 25 a 40% da RAM do servidor.
• work_mem: Memória pra operações de ordenação e hash em uma query. Quanto maior o valor, mais operações temporárias rolam na RAM (e não no disco).

2. Checando as configurações atuais de memória.

Pra ver quais configs de memória tão ativas no PostgreSQL, roda:

SHOW shared_buffers;
SHOW work_mem;

Exemplo de saída:

1GB
4MB

Isso quer dizer que o servidor reservou 1GB de RAM pra shared_buffers e 4MB pra cada operação de ordenação/hash.

3. Monitorando memória com pg_stat_activity

Dá pra ver quanta memória tá sendo usada pelas conexões ativas. Tem uma query massa pra isso:

SELECT pid, usename, state, backend_start, pg_size_pretty(pg_backend_memory_contexts_size(pid)) AS memory_used
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY memory_used DESC;

Essa query mostra quanta RAM cada conexão ativa tá usando.

Dica: se uma conexão tá usando RAM demais, confere se tem operações de ordenação ou agregação na query que podem ser otimizadas.

Monitorando o espaço em disco

O disco é o último reservatório de recursos pro PostgreSQL. Mesmo que você tenha RAM e CPU de sobra, o PostgreSQL precisa de espaço em disco pra guardar dados, logs de transação (WAL) e arquivos temporários.

1. Checando o tamanho do banco de dados.

Vamos começar pelo básico: descobrir o tamanho do banco.

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;

O que essa query faz?

Ela mostra o tamanho total do banco atual num formato amigável (MB, GB).

2. Checando o tamanho das tabelas e índices.

Pra descobrir quem são os "pesadões" do banco, usa:

SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Exemplo de saída:

3. Monitorando o WAL (logs de transação).

Se seu banco é bem movimentado, os logs de transação podem crescer rápido. Pra checar o tamanho deles:

SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), '0/0')) AS wal_size;

Conclusão

Agora você já tem as ferramentas e o conhecimento pra ficar de olho nas métricas sistêmicas do PostgreSQL:

1. Use htop ou pg_stat_activity pra monitorar a carga de CPU.
2. Ajuste os parâmetros shared_buffers e work_mem pra usar a RAM do jeito mais eficiente.
3. Cheque sempre o tamanho do banco, das tabelas e dos índices pra não ficar sem espaço em disco.

Essas skills vão te ajudar a evitar perrengues inesperados e manter o servidor PostgreSQL tinindo. Pensando no servidor, lembra: recursos bem organizados deixam seu produto bombando entre os clientes (usuários).