Alta Concorrência com Postgres
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Alta Concorrência com Postgres

  • 852 views
Uploaded 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......

Ú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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
852
On Slideshare
851
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
1

Embeds 1

https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  • 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. Sobre o que estamos falando? Figura: Metrˆ - SP / Esta¸˜o S´ o ca e
  • 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. 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. Gargalo de CPU Figura: Trem em Mulan - Paquist˜o a
  • 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. Lock Inferno Figura: Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek
  • 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. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  • 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. 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. 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. 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. 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. 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. 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. 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. Agenda Sobre o que estamos falando? Poss´ ıveis solu¸˜es co Considera¸˜es finais co Perguntas
  • 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. 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. 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. 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. Perguntas ? F´bio Telles Rodriguez a telles@timbira.com.br http://www.timbira.com.br