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

Alta Concorrência com Postgres

Embed Size (px)

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.

Citation preview

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.