Download - Alta Concorrência com Postgres
2©Bull 2012
Alta concorrência com PostgreSQL ou“Fazendo uma manada de elefantes
passarem debaixo da porta”
5©Bull 2012
Sobre o que estamos falando?
Aplicações OLTP com alta concorrência:Milhares de conexões simultâneasVá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.
6©Bull 2012
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.
8©Bull 2012
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.
9©Bull 2012
Gargalo de CPU
PGBouncer:1 Pool de conexões para transações utilizando o modo transaction1 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.
PGmemcacheReplicas 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;
11©Bull 2012
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;
12©Bull 2012
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;
13©Bull 2012
Ajustes no SO (Linux)
/etc/sysctl.confKernel.shmmax (¼ da RAM disponível)Semáforos (para suportar um número alto de conexões)File-maxOvercommit
/etc/security/limits.confNprocNofile
/etc/fstabNoatime para os dadosNoatime + writeback para o pg_xlog
14©Bull 2012
Ajustes no PostgreSQL
max_connectionsO menor número viável;Faça o possível e o impossível para diminuir este valor para menos de 500;
pg_hba.confLimite 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;
15©Bull 2012
Ajustes no PostgreSQL
Seja modesto com o shared buffersshared_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 < 16MBwork_mem < 16MBAjuste individualmente conexões específicas;
Aumente o checkpoint_segments Ajuste de acordo com o limite que o recover pode levar
16©Bull 2012
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;
17©Bull 2012
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;
18©Bull 2012
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 … SELECTAprenda 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.
19©Bull 2012
Fábio Telles [email protected]