O documento discute os desafios e soluções para aplicações OLTP com alta concorrência usando PostgreSQL, incluindo problemas de modelagem de dados e gerenciamento de conexões. Apresenta sugestões para otimizar o desempenho, como o ajuste de configurações de sistema e PostgreSQL, uso de caches e pools de conexões, além de recomendações de testes e monitoramento contínuo. Também destaca a importância de uma boa modelagem de dados e práticas de desenvolvimento para evitar problemas de desempenho.

1. Alta concorrˆncia com PostgreSQL
e
ou Fazendo uma manada de elefantes passar debaixo da porta
F´bio Telles Rodriguez
a
Timbira - A empresa brasileira de PostgreSQL
09 de novembro de 2012

2. Agenda
Sobre o que estamos falando?
Poss´
ıveis solu¸˜es
co
Considera¸˜es finais
co
Perguntas

3. Sobre esta apresenta¸˜o
ca
esta apresenta¸˜o est´ dispon´ em:
ca a ıvel
http://www.timbira.com.br/material
esta apresenta¸˜o est´ sob licen¸a Creative Commons
ca a c
Atribui¸˜o 3.0 Brasil:
ca
http://creativecommons.org/licenses/by/3.0/br

4. Sobre o que estamos falando?
Figura: Metrˆ - SP / Esta¸˜o S´
o ca e

5. Sobre o que estamos falando?
Aplica¸oes OLTP com alta concorrˆncia:
c˜ e
Milhares de conex˜es simultˆneas;
o a
V´rios usu´rios realizando grava¸˜es nas mesmas tabelas;
a a co
V´rias usu´rios consultando informa¸˜es que acabaram de ser
a a co
gravadas;
Cada usu´rio deve ser atendido em tempo h´bil;
a a
Crescimento de v´rios GBs por dia.
a

6. Tratamento Multi Documentos - TMD
Tratamento de imagens descentralizado em ambiente
bancario:
Crescimento de 5GB a 20GB por dia;
At´ 2 milh˜es documentos tratados por dia;
e o
Mais de 5 mil agˆncias com 10 mil esta¸˜es de captura.
e co
Pool de 25 servidores com complementa¸˜o autom´tica;
ca a
Mais de 500 esta¸˜es de complementa¸˜o manual;
co ca
Centenas de regras de neg´cio aplicadas para diversos tipos de
o
documento em diversas etapas (workflow);
Troca de informa¸˜es em lote com Mainframe;
co
Troca de informa¸˜es em XML com outros sistemas legados;
co
Exporta¸˜o de arquivos de sa´
ca ıda.
TUDO AO MESMO TEMPO, com janela de 6 horas de
processamento.

7. Gargalo de CPU
Figura: Trem em Mulan - Paquist˜o
a

8. Gargalo de CPU
SO n˜o trabalha bem com mais de 700 processos simultˆneos;
a a
O custo para gerenciar a fila de espera s´ aumenta o
o
problema;
Cada conex˜o precisa de mem´ria, keep alive pela rede e
a o
semaforiza¸˜o;
ca
O n´mero de conex˜es ativas no SGDB deve ficar na ´rdem
u o o
de 2 para cada core;
Aplica¸˜es server podem utilizar conex˜es persistentes...
co o
˜
... as aplica¸˜es client NAO;
co

9. Lock Inferno
Figura: Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek

10. Problemas com a modelagem
Modelagem de dados ruim pode levar anos para revelar um
resultado ruim.
Leva horas para mostrar a cat´strofe em alta concorrˆncia;
a e

11. Agenda
Sobre o que estamos falando?
Poss´
ıveis solu¸˜es
co
Considera¸˜es finais
co
Perguntas

12. Controlando o n´mero de conex˜es
u o
PGBouncer:
1 Pool de conex˜es para transa¸˜es no modo transaction;
o co
1 Pool de conex˜es para consultas no modo statement;
o
Aumento na eficiencia do processador, fila de espera das
transa¸˜es diminui;
co
PGmemcache
Replicas de dados do PostgreSQL para SQLite nas esta¸˜es
co
utiliza memcache;
Um gatilho nas tabelas replicadas atualiza o n´mero de vers˜o
u a
do cache;
Ao solicitar uma r´plica, a esta¸˜o compara a sua vers˜o da
e ca a
tabela com a vers˜o do cache;
a
Poderia ser implementado com Listem / Notify

13. Locks
S´ abra uma transa¸˜o, se realmente precisar;
o ca
Saiba quando abrir e quando fechar uma transa¸˜o; N˜o se
ca a
perca na aplica¸˜o;
ca
Se abrir, feche logo. N˜o espere eventos for a do SGDB para
a
fechar sua transa¸˜o;
ca
N˜o utilize SELECT ... FOR UPDATE;
a
N˜o utilize LOCKs expl´
a ıcitos. Tire proveito do MVCC;
DEAD LOCK s˜o problemas de l´gica da aplica¸˜o. Altere a
a o ca
l´gica dela;
o

14. Ajustes de Hardware
CPU r´pida ´ menos importante que ter muitos cores;
a e
Muita mem´ria RAM para manter um n´mer alto de
o u
conex˜es;
o
Use cache de disco para suportar um grande volume de
grava¸˜es concorrentes;
co
Discos r´pidos e separados para o pg xlog ´ imprecind´
a e ıvel;

15. Ajustes no SO (Linux)
/etc/sysctl.conf
kernel.shmmax (25% da RAM dispon´
ıvel)
Sem´foros (para suportar um n´mero alto de conex˜es)
a u o
file-max
overcommit
/etc/security/limits.conf
nproc
nofile
/etc/fstab
noatime para os dados
noatime + writeback para o pg xlog

16. Ajustes no PostgreSQL
max connections
O menor n´mero vi´vel;
u a
Fa¸a o poss´ para diminuir este valor para menos de 500;
c ıvel
pg hba.conf
Limite ao m´ximo a origem das suas conex˜es;
a o
Limite os usu´rios e bases que eles v˜o se conectar;
a a
Rejeite usu´rios, grupos e redes desconhecidos;
a

17. Ajustes no PostgreSQL
shared buffers
< 8GB ou 20% da RAM dispon´ (o que for maior);
ıvel
autovacuum
em tabelas que sofrem cargas pesadas em lote, desligue;
Mem´ria por processo
o
temp buffer < 16MB
work mem < 16MB
Ajuste individualmente conex˜es espec´
o ıficas;
checkpoint segments
Aumente para pelo menos 16
Limite de acordo com tempo que o recover pode levar

18. Acerte a sua modelagem
Use o tipo de dados certo para a tarefa certa;
Use chaves naturais;
N˜o use campos flex;
a
Para dados n˜o estruturados, vocˆ tem hstore, vetores e tipos
a e
compostos;
Use ´
ındices e gatilhos com sabedoria (teste e monitore o seu
uso);
Pilhas e filas n˜o devem ficar no seu SGDB;
a

19. Escrevendo SQL
Jamais utilize uma fun¸˜o em PL para algo que um SQL puro
ca
consegue fazer;
COMMIT a cada X altera¸˜es. X > 100 e < 100K;
co
Se uma consulta retorna mais de 100 registros, reveja a regra
de neg´cio;
o
INSERT < INSERT multiplo < PREPARE e EXECUTE <
COPY < INSERT ... SELECT
Aprenda a usar subconsultas e window functions e Common
Table Expression;
Relat´rios pesados devem utilizar vis˜es materializadas.
o o

20. Agenda
Sobre o que estamos falando?
Poss´
ıveis solu¸˜es
co
Considera¸˜es finais
co
Perguntas

21. Testes
Teste as funcionalidades
Teste com volumes de dados o mais realistas poss´
ıvel
Teste com carga de concorrˆncia o mais realista poss´
e ıvel

22. Rollout
Como testes com volume de dados e concorrˆncia nunca s˜o
e a
bons...
Fa¸a o deploy de poucas funcionalidades por vˆz;
c e
Adicione novos usu´rios aos poucos;
a
Esteja preparado para o caos durante o rollout;
N˜o tente matar mais de um le˜o por dia;
a a
O rollout de uma unica parte do sistema pode levar meses;
´

23. Monitoramento
Monitore o SO, o PostgreSQL, a aplica¸˜o;
ca
Gere logs que mostrem a opera¸˜o e a dura¸˜o de cada a¸˜o;
ca ca ca
Gere logs em formatos que possam ser manipulados por
ferramentas automatizadas;
Aprenda a configurar o log do PostgreSQL e o PGBadger;
Fa¸a coletas peri´dicas e armazene tudo em um local central;
c o
Crie baselines e compare sempre com elas;

24. Para os DBAs...
Durma bem antes de um novo deploy. Tire uns dias de folga;
N˜o deixe de tomar cerveja com os amigos...
a
Pratique exerc´
ıcios f´
ısicos regularmente!!!

25. Perguntas
?
F´bio Telles Rodriguez
a
telles@timbira.com.br
http://www.timbira.com.br