Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Alta concorrência com PostgreSQL

Alta concorrência com PostgreSQL

ou "Fazendo uma manada de elefantes passar debaixo da porta"

Palestra realizada no PGDay São Paulo

Fábio Telles Rodriguez

November 09, 2012
Tweet

More Decks by Fábio Telles Rodriguez

Other Decks in Programming

Transcript

  1. Alta concorrˆ encia com PostgreSQL ou Fazendo uma manada de

    elefantes passar debaixo da porta F´ abio Telles Rodriguez Timbira - A empresa brasileira de PostgreSQL 09 de novembro de 2012
  2. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸ c˜

    oes Considera¸ c˜ oes finais Perguntas
  3. Sobre esta apresenta¸ c˜ ao esta apresenta¸ c˜ ao est´

    a dispon´ ıvel em: http://www.timbira.com.br/material esta apresenta¸ c˜ ao est´ a sob licen¸ ca Creative Commons Atribui¸ c˜ ao 3.0 Brasil: http://creativecommons.org/licenses/by/3.0/br
  4. Sobre o que estamos falando? Aplica¸ c˜ oes OLTP com

    alta concorrˆ encia: Milhares de conex˜ oes simultˆ aneas; V´ arios usu´ arios realizando grava¸ c˜ oes nas mesmas tabelas; V´ arias usu´ arios consultando informa¸ c˜ oes que acabaram de ser gravadas; Cada usu´ ario deve ser atendido em tempo h´ abil; Crescimento de v´ arios GBs por dia.
  5. Tratamento Multi Documentos - TMD Tratamento de imagens descentralizado em

    ambiente bancario: Crescimento de 5GB a 20GB por dia; At´ e 2 milh˜ oes documentos tratados por dia; Mais de 5 mil agˆ encias com 10 mil esta¸ c˜ oes de captura. Pool de 25 servidores com complementa¸ c˜ ao autom´ atica; Mais de 500 esta¸ c˜ oes de complementa¸ c˜ ao manual; Centenas de regras de neg´ ocio aplicadas para diversos tipos de documento em diversas etapas (workflow); Troca de informa¸ c˜ oes em lote com Mainframe; Troca de informa¸ c˜ oes em XML com outros sistemas legados; Exporta¸ c˜ ao de arquivos de sa´ ıda. TUDO AO MESMO TEMPO, com janela de 6 horas de processamento.
  6. Gargalo de CPU SO n˜ ao trabalha bem com mais

    de 700 processos simultˆ aneos; O custo para gerenciar a fila de espera s´ o aumenta o problema; Cada conex˜ ao precisa de mem´ oria, keep alive pela rede e semaforiza¸ c˜ ao; O n´ umero de conex˜ oes ativas no SGDB deve ficar na ´ ordem de 2 para cada core; Aplica¸ c˜ oes server podem utilizar conex˜ oes persistentes... ... as aplica¸ c˜ oes client N˜ AO;
  7. Problemas com a modelagem Modelagem de dados ruim pode levar

    anos para revelar um resultado ruim. Leva horas para mostrar a cat´ astrofe em alta concorrˆ encia;
  8. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸ c˜

    oes Considera¸ c˜ oes finais Perguntas
  9. Controlando o n´ umero de conex˜ oes PGBouncer: 1 Pool

    de conex˜ oes para transa¸ c˜ oes no modo transaction; 1 Pool de conex˜ oes para consultas no modo statement; Aumento na eficiencia do processador, fila de espera das transa¸ c˜ oes diminui; PGmemcache Replicas de dados do PostgreSQL para SQLite nas esta¸ c˜ oes utiliza memcache; Um gatilho nas tabelas replicadas atualiza o n´ umero de vers˜ ao do cache; Ao solicitar uma r´ eplica, a esta¸ c˜ ao compara a sua vers˜ ao da tabela com a vers˜ ao do cache; Poderia ser implementado com Listem / Notify
  10. Locks S´ o abra uma transa¸ c˜ ao, se realmente

    precisar; Saiba quando abrir e quando fechar uma transa¸ c˜ ao; N˜ ao se perca na aplica¸ c˜ ao; Se abrir, feche logo. N˜ ao espere eventos for a do SGDB para fechar sua transa¸ c˜ ao; N˜ ao utilize SELECT ... FOR UPDATE; N˜ ao utilize LOCKs expl´ ıcitos. Tire proveito do MVCC; DEAD LOCK s˜ ao problemas de l´ ogica da aplica¸ c˜ ao. Altere a l´ ogica dela;
  11. Ajustes de Hardware CPU r´ apida ´ e menos importante

    que ter muitos cores; Muita mem´ oria RAM para manter um n´ umer alto de conex˜ oes; Use cache de disco para suportar um grande volume de grava¸ c˜ oes concorrentes; Discos r´ apidos e separados para o pg xlog ´ e imprecind´ ıvel;
  12. Ajustes no SO (Linux) /etc/sysctl.conf kernel.shmmax (25% da RAM dispon´

    ıvel) Sem´ aforos (para suportar um n´ umero alto de conex˜ oes) file-max overcommit /etc/security/limits.conf nproc nofile /etc/fstab noatime para os dados noatime + writeback para o pg xlog
  13. Ajustes no PostgreSQL max connections O menor n´ umero vi´

    avel; Fa¸ ca o poss´ ıvel para diminuir este valor para menos de 500; pg hba.conf Limite ao m´ aximo a origem das suas conex˜ oes; Limite os usu´ arios e bases que eles v˜ ao se conectar; Rejeite usu´ arios, grupos e redes desconhecidos;
  14. Ajustes no PostgreSQL shared buffers < 8GB ou 20% da

    RAM dispon´ ıvel (o que for maior); autovacuum em tabelas que sofrem cargas pesadas em lote, desligue; Mem´ oria por processo temp buffer < 16MB work mem < 16MB Ajuste individualmente conex˜ oes espec´ ıficas; checkpoint segments Aumente para pelo menos 16 Limite de acordo com tempo que o recover pode levar
  15. Acerte a sua modelagem Use o tipo de dados certo

    para a tarefa certa; Use chaves naturais; N˜ ao use campos flex; Para dados n˜ ao estruturados, vocˆ e tem hstore, vetores e tipos compostos; Use ´ ındices e gatilhos com sabedoria (teste e monitore o seu uso); Pilhas e filas n˜ ao devem ficar no seu SGDB;
  16. Escrevendo SQL Jamais utilize uma fun¸ c˜ ao em PL

    para algo que um SQL puro consegue fazer; COMMIT a cada X altera¸ c˜ oes. X > 100 e < 100K; Se uma consulta retorna mais de 100 registros, reveja a regra de neg´ ocio; INSERT < INSERT multiplo < PREPARE e EXECUTE < COPY < INSERT ... SELECT Aprenda a usar subconsultas e window functions e Common Table Expression; Relat´ orios pesados devem utilizar vis˜ oes materializadas.
  17. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸ c˜

    oes Considera¸ c˜ oes finais Perguntas
  18. Testes Teste as funcionalidades Teste com volumes de dados o

    mais realistas poss´ ıvel Teste com carga de concorrˆ encia o mais realista poss´ ıvel
  19. Rollout Como testes com volume de dados e concorrˆ encia

    nunca s˜ ao bons... Fa¸ ca o deploy de poucas funcionalidades por vˆ ez; Adicione novos usu´ arios aos poucos; Esteja preparado para o caos durante o rollout; N˜ ao tente matar mais de um le˜ ao por dia; O rollout de uma ´ unica parte do sistema pode levar meses;
  20. Monitoramento Monitore o SO, o PostgreSQL, a aplica¸ c˜ ao;

    Gere logs que mostrem a opera¸ c˜ ao e a dura¸ c˜ ao de cada a¸ c˜ ao; Gere logs em formatos que possam ser manipulados por ferramentas automatizadas; Aprenda a configurar o log do PostgreSQL e o PGBadger; Fa¸ ca coletas peri´ odicas e armazene tudo em um local central; Crie baselines e compare sempre com elas;
  21. Para os DBAs... Durma bem antes de um novo deploy.

    Tire uns dias de folga; N˜ ao deixe de tomar cerveja com os amigos... Pratique exerc´ ıcios f´ ısicos regularmente!!!