PostgreSQL e desempenho
O desempenho é um dos principais requisitos no projeto de arquitetura de software e tem sido o foco dos desenvolvedores do PostgreSQL desde o início, também mostrado no seguinte commit de fontes do PostgreSQL Git:
commit d31084e9d1118b25fd16580d9d8c2924b5740dff
Author: Marc G. Fournier <[email protected]>
Date: Tue Jul 9 06:22:35 1996 +0000
Postgres95 1.01 Distribution - Virgin Sources
[...]
diff --git a/src/backend/access/heap/stats.c b/src/backend/access/heap/stats.c
new file mode 100644
index 0000000000..d41d01ac1b
--- /dev/null
+++ b/src/backend/access/heap/stats.c
@@ -0,0 +1,329 @@
+/*-------------------------------------------------------------------------
+ *
+ * stats.c--
+ * heap access method debugging statistic collection routines
+ *
+ * Copyright (c) 1994, Regents of the University of California
[...]
+ * Also note that this routine probably shouldn't have to exist, and does
+ * screw up the call graph rather badly, but we are wasting so much time and
+ * system resources being massively general that we are losing badly in our
+ * performance benchmarks.
+ */O PostgreSQL alcança desempenho implementando vários recursos:
- Vários tipos de índice
- Planejador e otimizador de consultas que pode aproveitar os sistemas multiprocessadores
- MVCC
- Particionamento de tabela
Seleção do ambiente
Com as muitas opções disponíveis hoje, surgem muitas perguntas:
- No local ou na nuvem?
- Bare metal ou virtualizado?
- Hardware com marca ou criar o seu próprio?
- Como as funções de baixo nível do PostgreSQL ou o fsync afetam o desempenho do hardware?
- Disco local ou armazenamento compartilhado?
- Quais ajustáveis do sistema operacional precisam ser definidos?
Novamente, o wiki do PostgreSQL é um ponto de partida muito bom para todas as coisas sobre desempenho.
Quais são os principais itens a serem observados?
Como há muita literatura por aí abordando vários aspectos do ajuste de desempenho do PostgreSQL e design do sistema (dica:pesquise na página por xfs), este blog não pretende ser um mergulho profundo em nenhum dos tópicos já discutidos, mas sim um a perspectiva do sysadmin sobre por onde começar quando o foco principal é evitar a contenção de recursos. Também vou apontar muitas referências que abordam questões específicas com mais detalhes. Consultoria especializada em todas as áreas críticas para o desempenho do PostgreSQL está disponível por meio de muitas empresas que oferecem Serviços Profissionais.
Vamos começar!
Coleta de informações
Assumindo uma instalação padrão, e sabendo que o PostgreSQL não tenta ser bem ajustado fora da caixa e pode até haver algumas peculiaridades, esta etapa envolve a configuração das ferramentas de monitoramento necessárias.
Um bom monitoramento é fundamental para entender o aplicativo e rastrear rapidamente os recursos afetados, e isso é particularmente verdadeiro para provedores de nuvem em que o acesso ao host do banco de dados pode não estar disponível para executar benchmarks de CPU ou E/S:
Fig.1 — SlideShare, Jignesh Shah, Práticas recomendadas com PostgreSQL gerenciado na nuvem Reagindo aos alertas de desempenho do sistema
As ferramentas de monitoramento criarão gráficos e alertarão sobre os indicadores de desempenho do sistema:
CPU:
- Alerta — O alto uso indica uma consulta de longa duração.
- Impacto — tempo de resposta do aplicativo.
- Ação — revise as métricas de métricas de estatísticas do banco de dados para identificar as consultas que precisam de ajuste.
E/S:
- Alerta — Número alto ou leituras.
- Impacto — tempo de resposta do aplicativo.
- Ação — Adicione outra réplica de leitura. Revise as métricas de estatísticas do banco de dados para identificar consultas de longa duração.
- Alerta — Número alto de gravações.
- Impacto — tempo de resposta do aplicativo.
- Ação — Ajuste os parâmetros GUC shared_buffers, work_mem e maintenance_work_mem. Ajuste o checkpointer e certifique-se de que o autovacuum esteja ajustado corretamente. Se o PostgreSQL estiver instalado em seu próprio hardware, configure tablespaces e/ou considere a fragmentação, mas entenda as advertências sobre fragmentação.
Memória:
- Alerta — Alto uso de memória.
- Impacto — desempenho de E/S.
- Ação — revise as métricas de métricas de estatísticas do banco de dados para identificar as consultas que precisam de ajuste.
Rede:
- Alerta — Alta latência. Normalmente, esse é um problema de DBaaS.
- Impacto — Clientes, replicação.
- Ação — realoque os hosts do banco de dados para mais perto dos servidores front-end.
- Alerta — Número alto de conexões.
- Impacto — Clientes.
- Ação — Considere usar a sondagem de conexão.
Indicadores de desempenho interno do banco de dados
As visualizações pg_* são a janela para o desempenho do mecanismo de banco de dados, e os aplicativos de gerenciamento do PostgreSQL foram escritos para auxiliar na correlação da riqueza de informações disponíveis de outra forma por meio de várias consultas SQL. Extensões adicionais existem e geralmente são integradas ou disponibilizadas como plugins.
O uso dessas ferramentas simplifica a tarefa do DBA e garante que as práticas recomendadas sejam seguidas ao instalar e configurar o cluster de banco de dados.
Estatísticas do banco de dados
Ferramentas de monitoramento, como ClusterControl, usam estatísticas de atividade do banco de dados para auxiliar o DBA no ajuste de desempenho:
Fig.2 — Vários, principais coisas para monitorar no PostgreSQL — Analisando sua carga de trabalhoBaixe o whitepaper hoje PostgreSQL Management &Automation com ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper Ajuste de consulta
A partir da versão 9.5, o PostgreSQL inclui melhorias consideráveis no desempenho de consultas, como índices BRIN e consultas paralelas:
Fig.3 — 2ndQuadrant, Thomas Vondra, Performance Improvements in PostgreSQL 9.5 (e além) Bloqueio
O Concurrency Control é dedicado a um capítulo inteiro na documentação do PostgreSQL. Use ferramentas de monitoramento para ser alertado quando o número de bloqueios ou a duração do bloqueio exceder o limite e resolva o problema procurando índices ausentes, revisando o código do aplicativo ou alternando para a sondagem de conexão.
Carga em massa
synchronous_commit pode ser desativado durante grandes importações de dados. Mais opções são discutidas na seção de documentação do PostgreSQL Preenchendo um banco de dados.
Conclusão
O ajuste de desempenho do PostgreSQL é uma tarefa complexa. A complexidade vem dos muitos ajustes disponibilizados, o que é um forte argumento a favor do PostgreSQL. Não existe solução mágica para problemas de desempenho, mas sim as especificidades do aplicativo que determinam os requisitos de ajuste. Portanto, as ferramentas de monitoramento podem auxiliar na obtenção de insights de desempenho em relação ao desempenho do sistema e ainda permitem identificar as áreas específicas do PostgreSQL que precisam de ajuste, bem como as consultas SQL que exigem otimização. Além disso, os sistemas de gerenciamento de banco de dados podem ajudar na configuração e administração do PostgreSQL para garantir que as melhores práticas sejam seguidas.
