O documento discute estratégias para alta concorrência no PostgreSQL, incluindo ajustes de hardware, sistema operacional e configuração do banco de dados para suportar milhares de conexões simultâneas e crescimento de dados de vários GB por dia. Ele também fornece dicas sobre modelagem de dados, tratamento de transações e consultas para melhor desempenho.

1. Alta concorrência com
PostgreSQL
18 de Outubro de 2012 Fábio Telles Rodriguez
©Bull 2012 1

2. Alta concorrência com
PostgreSQL ou
“Fazendo uma manada de elefantes
passarem debaixo da porta”
©Bull 2012 2

3. Bull França
9º Lugar no top500.org
1º Lugar na Europa
©Bull 2012 3

4. Sobre o que estamos falando?
Metrô-SP / Estação SÉ
©Bull 2012 4

5. Sobre o que estamos falando?
Aplicações OLTP com alta concorrência:
Milhares de conexões simultâneas
Vários usuários realizando gravações nas mesmas tabelas;
Várias usuários consultando informações que acabaram
de ser gravadas;
Cada usuário deve ser atendido em tempo hábil;
Crescimento de vários GBs por dia.
©Bull 2012 5

6. Tratamento Multi Documentos - TMD
Tratamento de imagens decentralizado em
ambiente bancário:
Crescimento de até 50GB por dia;
Até 2 milhões documentos tratados por dia;
Mais de 5 mil agências com 10 mil estações de captura.
Pool de 25 servidores com complementação automática;
Mais de 500 estações de complementação manual;
Centenas de regras de negócio aplicadas para diversos
tipos de documento em diversas etapas (workflow);
Troca de informações em lote com Mainframe;
Troca de informações em XML com outros sistemas
legados;
Exportação de arquivos de saída.
TUDO AO MESMO TEMPO, com janela de 6 horas
de processamento.
©Bull 2012 6

7. Gargalo de CPU
Trem em Mulan - Paquistão
©Bull 2012 7

8. Gargalo de CPU
SO não trabalha bem com mais de 700 processos
simultâneos;
O custo para gerenciar a fila de espera de CPU só
aumenta o problema;
Cada conexão precisa de memória alocada, sinais
de keep alive pela rede e semaforização;
Mantenha o volume de conexões no SGDB na
órdem de 2 para cada core;
Aplicações server podem utilizar conexões
persistentes, aplicações client NÃO.
©Bull 2012 8

9. Gargalo de CPU
PGBouncer:
1 Pool de conexões para transações utilizando o modo
transaction
1 Pool de conexões para consultas no modo statement;
Com o aumento na eficiencia do processador, a fila de
espera das transações diminuiu de 2000 para 10.
PGmemcache
Replicas de dados do PostgreSQL para SQLite nas
estações utiliza memcache;
Um gatilho nas tabelas replicadas atualiza o número de
versão do cache;
Ao solicitar uma réplica, a estação compara a sua versão
da tabela com a versão do cache;
©Bull 2012 9

10. Locks
Cruzamento das Avenidas Faria Lima com a Juscelino
Kubitschek em São Paulo.
©Bull 2012 10

11. Locks
Só abra uma transação, se realmente prcisar;
Saiba quando abrir e quando fechar uma
transação; Não se perca na aplicação;
Se abrir, feche logo. Não espere eventos for a do
SGDB para fechar sua transação;
Não utilize SELECT … FOR UPDATE;
Não utilize LOCKs explícitos. Tire proveito do
MVCC;
DEAD LOCK são problemas de lógica da aplicação.
Se eles aparecem, altere radicalmente a lógica
dela;
©Bull 2012 11

12. Ajustes de hardware
Ter a CPU mais rápida é menos importante que ter
muitos cores;
Você precisa de muita memória RAM para manter
um númer alto de conexões;
Cache de disco é fundamental para suportar um
grande volume de gravações concorrentes;
Discos rápidos e separados para o pg_xlog é
imprecindível;
©Bull 2012 12

13. Ajustes no SO (Linux)
/etc/sysctl.conf
Kernel.shmmax (¼ da RAM disponível)
Semáforos (para suportar um número alto de conexões)
File-max
Overcommit
/etc/security/limits.conf
Nproc
Nofile
/etc/fstab
Noatime para os dados
Noatime + writeback para o pg_xlog
©Bull 2012 13

14. Ajustes no PostgreSQL
max_connections
O menor número viável;
Faça o possível e o impossível para diminuir este valor
para menos de 500;
pg_hba.conf
Limite ao máximo de ONDE as suas conexões vem;
Limite os usuários e bases que eles vão se conectar;
Rejeite usuários, grupos e redes desconhecidos;
©Bull 2012 14

15. Ajustes no PostgreSQL
Seja modesto com o shared buffers
shared_buffer < 8GB ou 1/6 da RAM disponível (o que for
maior);
Ajuste o autovacuum cuidadoramente;
desligue e faça manualmente em cargas pesadas;
Limite bem a memória por processo:
temp_buffer < 16MB
work_mem < 16MB
Ajuste individualmente conexões específicas;
Aumente o checkpoint_segments
Ajuste de acordo com o limite que o recover pode levar
©Bull 2012 15

16. Acerte a sua modelagem
Modelagem de dados ruim pode levar anos para
revelar um resultado ruim.
Leva horas para mostrar a catástrofe em alta
concorrência;
©Bull 2012 16

17. Acerte sua modelagem
Use o tipo de dados certo para a tarefa certa;
Use chaves naturais;
Para dados não estruturados, você tem hstore,
vetores e tipos compostos;
Não use campos flex;
Use índices e gatilhos com sabedoria;
Teste e monitore o seu uso;
Pilhas e filhas não devem ficar no seu SGDB;
©Bull 2012 17

18. DML
COMMIT a cada X alterações. X > 100 e < 100K;
Se uma consulta retorna mais de 100 registros,
algo está errado, reveja a regra de negócio;
INSERT < INSERT multiplo < PREPARE e EXECUTE
< COPY < INSERT … SELECT
Aprenda a usar subconsultas e window functions e
Common Table Expression;
Jamais utilize uma função em PL para algo que um
SQL puro consegue fazer
Relatórios pesados devem utilizar visões
materializadas.
©Bull 2012 18

19. Fábio Telles Rodriguez
fabio.rodriguez@lam-bull.com
fabio.telles@gmail.com
©Bull 2012 19