Alta Concorrência com Postgres

Alta Concorrência com Postgres

• 1.
  Alta concorrência com PostgreSQL 18 de Outubro de 2012 Fábio Telles Rodriguez ©Bull 2012 1
• 2.
  Alta concorrência com PostgreSQL ou “Fazendo uma manada de elefantes passarem debaixo da porta” ©Bull 2012 2
• 3.
  Bull França 9º Lugar no top500.org 1º Lugar na Europa ©Bull 2012 3
• 4.
  Sobre o queestamos falando? Metrô-SP / Estação SÉ ©Bull 2012 4
• 5.
  Sobre o queestamos 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. ©Bull 2012 5
• 6.
  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. ©Bull 2012 6
• 7.
  Gargalo de CPU Trem em Mulan - Paquistão ©Bull 2012 7
• 8.
  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. ©Bull 2012 8
• 9.
  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; ©Bull 2012 9
• 10.
  Locks Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek em São Paulo. ©Bull 2012 10
• 11.
  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; ©Bull 2012 11
• 12.
  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; ©Bull 2012 12
• 13.
  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 ©Bull 2012 13
• 14.
  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; ©Bull 2012 14
• 15.
  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 ©Bull 2012 15
• 16.
  Acerte a suamodelagem Modelagem de dados ruim pode levar anos para revelar um resultado ruim. Leva horas para mostrar a catástrofe em alta concorrência; ©Bull 2012 16
• 17.
  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; ©Bull 2012 17
• 18.
  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. ©Bull 2012 18
• 19.
  Fábio Telles Rodriguez fabio.rodriguez@lam-bull.com fabio.telles@gmail.com ©Bull 2012 19