Um pouco de cuidado e preparação de sua implantação do PostgreSQL ajuda bastante a garantir o desempenho, evitando descobertas desagradáveis e estabelecendo uma previsibilidade confiável. Aqui estão 7 coisas que você deve ficar de olho.
Tabela inchada
O PostgreSQL implementa transações usando uma técnica chamada MVCC.MVCC é muito longo e envolve um tópico a ser discutido em detalhes, mas existemtrês coisas que você deve saiba disso:
- A exclusão de uma linha apenas a marca como "invisível" para transações futuras.
- A atualização de uma linha cria uma nova versão da linha. A versão antiga é marcada como invisível para transações futuras e a nova versão é marcada como visível.
- Periodicamente, alguém precisa examinar todas as transações em execução no momento e dizer:OK, a transação mais antiga aqui é a nº 42, então cada versão de linha invisível para a nº 42 pode ser excluída fisicamente sem prejudicar a consistência dos dados.
É assim que o MVCC funciona (essencialmente), e a implicação é que as atualizações irão aumentar o espaço físico de armazenamento do banco de dados e as exclusões não reduzi-lo. MVCC soa como uma maneira preguiçosa de fazer as coisas, mas é popular porque fornece consistência e desempenho.
As versões de linha indesejadas e obsoletas em uma tabela são chamadas de bloat (ou deadrows ). O processo que pode eliminar o inchaço é chamado de vácuo . O PostgreSQL tem um processo de vácuo acionado automaticamente com limites ajustáveis chamados autovacuum e, claro, o comando VACUUM.
Em geral, o inchaço também pode tornar as consultas mais lentas devido a mapas de visibilidade imprecisos e E/S de disco desperdiçado.
Por isso, você deve regularmente:
- monitorar a quantidade de inchaço em um banco de dados
- execute o vácuo regularmente
- monitorar se o vácuo está sendo executado regularmente para todas as tabelas
Existem algumas consultas SQL para fornecer estimativas de bloat por tabela. A ferramenta open source fornece estimativas de bloat, bem como os últimos tempos de execução de vácuo manual e automático.
Indexação inchada
Os índices também podem inchar. Embora a estrutura interna dos índices seja opaca para o usuário SQL e varie de acordo com o tipo de índice (BTree, hash, GIN, GIST, etc.), permanece a ideia geral de que quando as linhas referenciadas pelo índice são excluídas, o espaço ocupado pelas informações relacionadas dentro do índice é excluído apenas logicamente e não é liberado de volta para o sistema de arquivos. O espaço excluído logicamente pode ser reutilizado pelo índice posteriormente.
Existem duas maneiras de fazer com que o Postgres reduza o tamanho físico de um índice:
- a versão COMPLETA do comando VACUUM
- REINDEX
O inchaço do índice deve ser monitorado, para que você esteja pelo menos ciente da quantidade de espaço restante não utilizada. Em tabelas com alta rotatividade de linhas, não é incomum configurar trabalhos regulares de reconstrução de índice.
O inchaço do índice também pode ser obtido pelas mesmas consultas anteriores e também via pgmetrics.
Transações de longa duração
As transações devem ser mantidas o mais curtas possível, especialmente em um sistema MVCC.
Imagine que uma transação começou ontem e houve um vácuo logo depois disso. Agora, enquanto esta transação estiver aberta, mais vácuos são inúteis, pois, por definição, nossa transação precisará ver todas as linhas de todas as tabelas como estavam quando nossa transação começou ontem. Mesmo que nossa transação seja somente leitura, esse ainda é o caso.
Como resultado, transações de longa duração criam inchaço. Eles também se apegam aos recursos do sistema, mantêm bloqueios não liberados e aumentam as chances de bloqueios.
A melhor maneira de ficar de olho em transações de longa duração é configurar um alerta para o número de transações que estão em execução por mais de um determinado período. Você pode obter isso na visualização de estatísticas
pg_stat_activity , igual a:-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Atraso de replicação
Quando a replicação de streaming é usada para replicar todas as alterações de um servidor PostgreSQL primário para um hot standby (também conhecido como réplica de leitura), geralmente há um pequeno atraso entre o momento em que as atualizações de linha ocorrem no primário e quando as alterações são visíveis para os aplicativos conectados ao standby .
No entanto, existem casos em que esse atraso pode aumentar:
- o sistema em espera não consegue receber e aplicar as alterações do primário rápido o suficiente para acompanhá-lo, geralmente devido à alta carga ou subprovisionamento
- uma rede ou disco degradado
- conflitos de consulta
Um standby com um atraso de replicação alto ou pior ainda, crescente, pode resultar em consultas no standby retornando dados obsoletos e um standby que não é adequado para failover.
Se você tiver uma configuração de replicação de streaming, o monitoramento de atrasos de replicação entre cada par primário-standby é muito importante, e você desejará configurar alertas para verificar se os atrasos de replicação excedem um minuto ou qualquer limite que faça sentido para sua configuração.
Esta postagem tem muito mais sobre como medir e monitorar o atraso de replicação das extremidades primária e de espera.
Slots de replicação inativos
O uso de slots de replicação, introduzidos no PostgreSQL 9.4, torna a replicação de streaming mais robusta e eficiente. Essencialmente, o standby informa o progresso da replicação para o primário, que armazena essas informações no “slot de replicação”.
Por causa disso, o primário agora sabe o tempo todo o quão atrasado está o standby. Isso permite que o primário retenha uma lista de pendências suficiente de arquivos WAL (que são necessários para retomar a replicação) quando o modo de espera ficar offline. Assim, quando o standby volta, mesmo depois de muito tempo, o primário ainda pode garantir que a replicação possa ser retomada.
Antes dos slots de replicação, o primário pode limpar arquivos WAL antigos, pois não tinha como saber se os standbys precisavam deles ou não. Se um arquivo WAL necessário para o modo de espera for excluído, não há como retomar a replicação; ele tem que ser configurado novamente do zero.
No entanto, o comportamento do primário de reter arquivos WAL indefinidamente leva a outro problema. Se uma espera foi retirada e o slot de replicação associado não foi excluído, os arquivos WAL serão retidos para sempre. Os arquivos WAL retidos por esse motivo não estão sujeitos aos limites definidos por
max_wal_size e outras opções de configuração. Essa situação persistirá até que os arquivos WAL consumam todo o espaço em disco, sem nem mesmo um aviso nos arquivos de log do PostgreSQL.
Desnecessário dizer que os slots de replicação inativos devem ser tratados quando forem detectados. Encontre seus slots de replicação inativos usando:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analisar status
ANALYZE é executado em tabelas para coletar e atualizar informações estatísticas sobre o conteúdo da tabela. Essas informações são usadas pelo planejador de consultas para preparar o plano de execução para cada consulta SQL. Estatísticas atualizadas sobre o conteúdo da tabela resultam em um melhor plano de execução, o que, por sua vez, resulta em uma consulta mais rápida.
O daemon de autovacuum geralmente executa ANALYZE após VACUUM. No entanto, isso pode não ser frequente o suficiente para ANALISAR. Se a distribuição dos dados em uma tabela muda com frequência, você deve executar ANALYZE com mais frequência.
Normalmente, ANALYZE é muito bem comportado – ele precisa apenas de bloqueios de leitura, não consome muito de nenhum recurso e é concluído em um tempo razoável. É seguro toerr do lado de executá-lo com mais frequência do que não.
Ficar de olho nas tabelas que não são ANALIZADAS há algum tempo é uma boa ideia. Descubra a última vez que suas tabelas foram (auto-)analisadas com a consulta:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Uso de recursos
Monitorar a carga da CPU, a memória e o uso do disco ajuda bastante a garantir que você tenha capacidade suficiente disponível para atender às crescentes necessidades dos aplicativos que usam seu banco de dados.
O PostgreSQL gera um processo para lidar com uma conexão. Embora esta não seja a arquitetura mais escalável hoje em dia, ela contribui muito na frente da estabilidade. Também torna a média de carga do SO mais significativa. Como normalmente os PostgreSQLboxes executam apenas o PostgreSQL, uma média de carga de digamos 3 normalmente significa que há 3 conexões esperando que os núcleos da CPU fiquem disponíveis para que possam ser escalonados. Monitorar sua média de carga máxima durante um dia ou semana típico pode dar uma estimativa de quão super ou subprovisionada sua caixa está na frente da CPU.
Memória e espaço livre em disco são coisas padrão para monitorar. Mais conexões e transações mais longas exigem mais memória. E enquanto monitora o espaço livre em disco, lembre-se de rastreá-lo por tablespace.
