Alta Concorrência com Postgres

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

description

Versão da palestra "Fazendo uma manada de elefantes passarem debaixo da porta" para o Latinoware 2012. A palestra fala sobre cuidados para trabalhar com PostgreSQL em ambientes OLTP de alta concorrência.

Transcript of Alta Concorrência com Postgres

1©Bull 2012

Alta concorrência com PostgreSQL

Fábio Telles Rodriguez18 de Outubro de 2012

2©Bull 2012

Alta concorrência com PostgreSQL ou“Fazendo uma manada de elefantes

passarem debaixo da porta”

3©Bull 2012

Bull França

9º Lugar no top500.org1º Lugar na Europa

4©Bull 2012

Sobre o que estamos falando?

Metrô-SP / Estação SÉ

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.

7©Bull 2012

Gargalo de CPU

Trem em Mulan - Paquistão

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;

10©Bull 2012

Locks

Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek em São Paulo.

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.