O documento discute a otimização do PostgreSQL, abordando problemas comuns relacionados a SQL mal escrito, modelagem inadequada e ajustes errôneos em hardware e software. Apresenta recomendações para o ajuste do sistema operacional, hardware e parâmetros do PostgreSQL, enfatizando a importância do monitoramento e do uso de boas práticas. Também ressalta a relevância de uma arquitetura sólida e a escolha correta de tipos de dados e estruturas para melhorar o desempenho do banco de dados.

1. Tunning PostgreSQL em modo
OGRO

2. Quem está aqui??
Gerdan Rezende dos Santos

Líder Técnico e Consultor em Banco de Dados e na Tecnisys
Tecnologias inovadoras

Graduado em Ciências da Computação pela Universidade Paulista

Pós-graduado em Sistemas de Informação e Aplicações WEB

Pós-graduado em Sistemas de Informação Orientação a Objetos

MCT em SQLServer e .NET

Ativo nas comunidades PostgreSQL nacional e internacional,
colaborador principalmente nos testes de novas funcionalidades.

Já trabalhou em grandes Data Centers, como: MEC/Fies, MJ/PRF,
MME/DNPM, MCTI, Cluster Ativo x Ativo Armazém Paraíba,
TRT/PJe,

3. TECNISYS
➢
Atuando como provedora de
soluções tecnológicas a mais
de 25 anos. Somos referência
nacional em tecnologia
Open Source.
➢
Temos parcerias de sucesso
firmadas com empresas de
renome mundial,
fornecendo suporte técnico,
consultoria, treinamentos
oficiais e certificações

4. SEGMENTOS DE ATUAÇÃO

5. O QUE VEREMOS?
SEGURANÇA
CUSTO
DESEMPENHO

6. NÃO É

7. ONDE COMEÇA O PROBLEMA
CRUD

8. E QUAL A RELAÇÃO ?
FONTE: STORAGE TECNOLOGY – PRICE, PERFORMANDO & CAPACITY SUN

9. LOG TRANSACIONAL - WAL
Após um COMMIT um registro de WAL é gerado;
Após um checkpoint os DATAFILES são atualizados;
Se houver problemas o PostgreSQL vai recorrer ao
WAL(restart, falhas, rollback);

10. Onde está o problema mesmo ?
50% estão em SQL mal escrito;
25% estão em modelagem de dados mal feita;
15% estão em ajustes errôneos do SGBD;
5% estão em ajustes ruins do S.O.; e
5% estão em hardware mal dimensionado

11. Onde??? Hardware
✔ Servidor dedicado;
✔ Disco dedicados;
✔ Você vai definir o ambiente? Ótimo… Discos,
memória e processador;
✔ SSD SLC > SSD MLC > Fiber Channel > SAS >
jogue os SATA FORA;
✔ RAID 10> RAID 1 > RAID 6 > RAID 5
✔ Processadores? Quantos mais cache e memória
melhor...

12. Onde??? S.O.
✔ O melhor é aquele que você tem domínio
✔ É obrigatório utilizar no mínimo arquitetura 64bits
✔ RAID por software NÃO EkxisISTE - Pe. Kevedo
✔ Se possível descarte abstração de
particionamento por software “LVM”
✔ Remova qualquer serviço que não for necessário:
Bluetooth, Apache, Int. Gráfica, etc…
✔ Aprenda muito, mas muito mesmo Linux – Ref.
item 01

13. Onde??? Discos
✔ / Pergunte ao SysAdmin senão ext4 nele
✔ /boot Pergunte ao SysAdmin senão ext4 nele
✔ PGDATA (RAID 10 OU 1 + XFS OU EXT4 + noatime)
✔ pg_xlog (ext3 + noatime + writeback)
✔ Tablespaces com dados históricos (RAID 5 com
XFS ou EXT4 + noatime)
✔ BACKUP E ARCHIVES (Lembra dos SATA, pegue
eles de volta do lixo)

14. Ajustes no S.O.
✔ Aprender o Linux
✔ Sysctl.conf
✔ Semáforos;
✔ kernel.shmmax (½ da RAM disponível);
✔ file-max;
✔ overcommit;
✔ Limits.conf
✔ nofile;
✔ nproc;
✔ fstab
✔ Noatime para o banco
✔ +Writeback para o pg_xlog;

15. Ajustes no PostgreSQL
✔ max_connections: menor número possível;
✔ shared_buffers: 8GB ou ¼ da RAM disponível;
✔ maintenance_work_mem: a maior tabela do seu
catalogo, senão grande o suficiente para ser maior
que 75% das tabelas;
✔ checkpoint_segments: entre 16 e 128;
✔ checkpoint_timeout: entre 10min e 30min;
✔ Se possível utilize um pool de conexões: PgBouncer;
✔ Sempre monitore e ajuste apenas 1 item por vez;

16. Ajustes no PostgreSQL
✔ max_connections: menor número possível;
✔ shared_buffers: 8GB ou ¼ da RAM disponível;
✔ maintenance_work_mem: a maior tabela do seu catalogo, senão
grande o suficiente para ser maior que 75% das tabelas;
✔ checkpoint_segments: entre 16 e 128;
✔ checkpoint_timeout: entre 10min e 30min;
✔ Jamais desligue o autovacuum
✔ Se possível utilize um pool de conexões: PgBouncer;
✔ Sempre monitore e ajuste apenas 1 item por vez;

17. Ajustes no Modelo de Dados
✔ Use o tipo de dados certo para cada coisa;
✔ PK? procure usar naturais, CPF não é chave
natural ;)
✔ Tabela genérica, campo flex – Se existir remova e
nem pergunte quem criou… Seja mau.
✔ Monitore todos objetos – Você é obrigado a
conhecer o que onera seu banco
✔ ESTRUTURAS DE DADOS FICAM NA APLICAÇÃO
(PILHAS E FILAS)
PostgreS

18. Ajuste na Linguagem
✔ Aprenda Linux… Só pra não esquecer ;)
✔ Se o SQL resolve… Então basta
✔ Procure controlar o tamanho de suas transações
✔ Monitore todos objetos – Você é obrigado a
conhecer o que onera seu banco e como onera
✔ Para relatórios, faça o possível para utilizar views
materializadas
✔ INSERT < INSERT múltiplo < Prepared Trans ??? <
copy < insert .. select
PostgreS

19. Considerações Finais

20. Considerações Finais

21. Considerações Finais

22. Perguntas ??

23. Parceiros

24. Telefones: (61) 3039-9700 / FAX: (61) 3039-9701
E-mail: comercial@tecnisys.com.br
Visite nosso site http://www.tecnisys.com.br
Contato

25. Obrigado!
www.linkedin.com/in/gerdan