Alta concorrência com PostgreSQL

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.

Transcript

1. 1 ©Bull 2012 Alta concorrência com PostgreSQL Fábio Telles Rodriguez 18 de Outubro de 2012
2. 2 ©Bull 2012 Alta concorrência com PostgreSQL ou “Fazendo uma manada de elefantes passarem debaixo da porta”
3. 3 ©Bull 2012 Bull França 9º Lugar no top500.org 1º Lugar na Europa
4. 4 ©Bull 2012 Sobre o que estamos falando? Metrô-SP / Estação SÉ
5. 5 ©Bull 2012 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.
6. 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. 7 ©Bull 2012 Gargalo de CPU Trem em Mulan - Paquistão
8. 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. 9 ©Bull 2012 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;
10. 10 ©Bull 2012 Locks Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek em São Paulo.
11. 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. 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. 13 ©Bull 2012 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
14. 14 ©Bull 2012 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;
15. 15 ©Bull 2012 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
16. 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. 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. 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 … 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.
19. 19 ©Bull 2012 Fábio Telles Rodriguez fabio.rodriguez@lam-bull.com fabio.telles@gmail.com