Alta Concorrência com Postgres

783 views
697 views

Published on

Última versão da palestra "Fazendo uma manada de elefantes passarem debaixo da porta", ministrada no PGDay São Paulo 2012, em 09/11. Esta é a versão definitiva, não pretendo atualizar ou ministrar novamente esta palestra.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Alta Concorrência com Postgres

  1. 1. Alta concorrˆncia com PostgreSQL eou Fazendo uma manada de elefantes passar debaixo da porta F´bio Telles Rodriguez a Timbira - A empresa brasileira de PostgreSQL 09 de novembro de 2012
  2. 2. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  3. 3. Sobre esta apresenta¸˜o ca esta apresenta¸˜o est´ dispon´ em: ca a ıvel http://www.timbira.com.br/material esta apresenta¸˜o est´ sob licen¸a Creative Commons ca a c Atribui¸˜o 3.0 Brasil: ca http://creativecommons.org/licenses/by/3.0/br
  4. 4. Sobre o que estamos falando? Figura: Metrˆ - SP / Esta¸˜o S´ o ca e
  5. 5. Sobre o que estamos falando? Aplica¸oes OLTP com alta concorrˆncia: c˜ e Milhares de conex˜es simultˆneas; o a V´rios usu´rios realizando grava¸˜es nas mesmas tabelas; a a co V´rias usu´rios consultando informa¸˜es que acabaram de ser a a co gravadas; Cada usu´rio deve ser atendido em tempo h´bil; a a Crescimento de v´rios GBs por dia. a
  6. 6. Tratamento Multi Documentos - TMD Tratamento de imagens descentralizado em ambiente bancario: Crescimento de 5GB a 20GB por dia; At´ 2 milh˜es documentos tratados por dia; e o Mais de 5 mil agˆncias com 10 mil esta¸˜es de captura. e co Pool de 25 servidores com complementa¸˜o autom´tica; ca a Mais de 500 esta¸˜es de complementa¸˜o manual; co ca Centenas de regras de neg´cio aplicadas para diversos tipos de o documento em diversas etapas (workflow); Troca de informa¸˜es em lote com Mainframe; co Troca de informa¸˜es em XML com outros sistemas legados; co Exporta¸˜o de arquivos de sa´ ca ıda. TUDO AO MESMO TEMPO, com janela de 6 horas de processamento.
  7. 7. Gargalo de CPU Figura: Trem em Mulan - Paquist˜o a
  8. 8. Gargalo de CPU SO n˜o trabalha bem com mais de 700 processos simultˆneos; a a O custo para gerenciar a fila de espera s´ aumenta o o problema; Cada conex˜o precisa de mem´ria, keep alive pela rede e a o semaforiza¸˜o; ca O n´mero de conex˜es ativas no SGDB deve ficar na ´rdem u o o de 2 para cada core; Aplica¸˜es server podem utilizar conex˜es persistentes... co o ˜ ... as aplica¸˜es client NAO; co
  9. 9. Lock Inferno Figura: Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek
  10. 10. Problemas com a modelagem Modelagem de dados ruim pode levar anos para revelar um resultado ruim. Leva horas para mostrar a cat´strofe em alta concorrˆncia; a e
  11. 11. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  12. 12. Controlando o n´mero de conex˜es u o PGBouncer: 1 Pool de conex˜es para transa¸˜es no modo transaction; o co 1 Pool de conex˜es para consultas no modo statement; o Aumento na eficiencia do processador, fila de espera das transa¸˜es diminui; co PGmemcache Replicas de dados do PostgreSQL para SQLite nas esta¸˜es co utiliza memcache; Um gatilho nas tabelas replicadas atualiza o n´mero de vers˜o u a do cache; Ao solicitar uma r´plica, a esta¸˜o compara a sua vers˜o da e ca a tabela com a vers˜o do cache; a Poderia ser implementado com Listem / Notify
  13. 13. Locks S´ abra uma transa¸˜o, se realmente precisar; o ca Saiba quando abrir e quando fechar uma transa¸˜o; N˜o se ca a perca na aplica¸˜o; ca Se abrir, feche logo. N˜o espere eventos for a do SGDB para a fechar sua transa¸˜o; ca N˜o utilize SELECT ... FOR UPDATE; a N˜o utilize LOCKs expl´ a ıcitos. Tire proveito do MVCC; DEAD LOCK s˜o problemas de l´gica da aplica¸˜o. Altere a a o ca l´gica dela; o
  14. 14. Ajustes de Hardware CPU r´pida ´ menos importante que ter muitos cores; a e Muita mem´ria RAM para manter um n´mer alto de o u conex˜es; o Use cache de disco para suportar um grande volume de grava¸˜es concorrentes; co Discos r´pidos e separados para o pg xlog ´ imprecind´ a e ıvel;
  15. 15. Ajustes no SO (Linux) /etc/sysctl.conf kernel.shmmax (25% da RAM dispon´ ıvel) Sem´foros (para suportar um n´mero alto de conex˜es) a u o file-max overcommit /etc/security/limits.conf nproc nofile /etc/fstab noatime para os dados noatime + writeback para o pg xlog
  16. 16. Ajustes no PostgreSQL max connections O menor n´mero vi´vel; u a Fa¸a o poss´ para diminuir este valor para menos de 500; c ıvel pg hba.conf Limite ao m´ximo a origem das suas conex˜es; a o Limite os usu´rios e bases que eles v˜o se conectar; a a Rejeite usu´rios, grupos e redes desconhecidos; a
  17. 17. Ajustes no PostgreSQL shared buffers < 8GB ou 20% da RAM dispon´ (o que for maior); ıvel autovacuum em tabelas que sofrem cargas pesadas em lote, desligue; Mem´ria por processo o temp buffer < 16MB work mem < 16MB Ajuste individualmente conex˜es espec´ o ıficas; checkpoint segments Aumente para pelo menos 16 Limite de acordo com tempo que o recover pode levar
  18. 18. Acerte a sua modelagem Use o tipo de dados certo para a tarefa certa; Use chaves naturais; N˜o use campos flex; a Para dados n˜o estruturados, vocˆ tem hstore, vetores e tipos a e compostos; Use ´ ındices e gatilhos com sabedoria (teste e monitore o seu uso); Pilhas e filas n˜o devem ficar no seu SGDB; a
  19. 19. Escrevendo SQL Jamais utilize uma fun¸˜o em PL para algo que um SQL puro ca consegue fazer; COMMIT a cada X altera¸˜es. X > 100 e < 100K; co Se uma consulta retorna mais de 100 registros, reveja a regra de neg´cio; o INSERT < INSERT multiplo < PREPARE e EXECUTE < COPY < INSERT ... SELECT Aprenda a usar subconsultas e window functions e Common Table Expression; Relat´rios pesados devem utilizar vis˜es materializadas. o o
  20. 20. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  21. 21. Testes Teste as funcionalidades Teste com volumes de dados o mais realistas poss´ ıvel Teste com carga de concorrˆncia o mais realista poss´ e ıvel
  22. 22. Rollout Como testes com volume de dados e concorrˆncia nunca s˜o e a bons... Fa¸a o deploy de poucas funcionalidades por vˆz; c e Adicione novos usu´rios aos poucos; a Esteja preparado para o caos durante o rollout; N˜o tente matar mais de um le˜o por dia; a a O rollout de uma unica parte do sistema pode levar meses; ´
  23. 23. Monitoramento Monitore o SO, o PostgreSQL, a aplica¸˜o; ca Gere logs que mostrem a opera¸˜o e a dura¸˜o de cada a¸˜o; ca ca ca Gere logs em formatos que possam ser manipulados por ferramentas automatizadas; Aprenda a configurar o log do PostgreSQL e o PGBadger; Fa¸a coletas peri´dicas e armazene tudo em um local central; c o Crie baselines e compare sempre com elas;
  24. 24. Para os DBAs... Durma bem antes de um novo deploy. Tire uns dias de folga; N˜o deixe de tomar cerveja com os amigos... a Pratique exerc´ ıcios f´ ısicos regularmente!!!
  25. 25. Perguntas ? F´bio Telles Rodriguez a telles@timbira.com.br http://www.timbira.com.br

×