Fazendo uma manada de elefantes passar por baixo da porta

926 views
822 views

Published on

Trabalhar com alta concorrência em banco de dados exigem muitos cuidados. Esta palestra visa exibir alguns cuidados e boas práticas no desenvolvimento de aplicações OLTP com alta concorrência. Os cuidados vão da configuração do hardware, SO, storage e do PostgreSQL, até a modelagem de dados, ajustes de parâmetros individuais em alguns objetos e principalmente: ajuste de processos na aplicação.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
926
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Fazendo uma manada de elefantes passar por baixo da porta

  1. 1. Fazendo uma manada de elefantes passar debaixo da porta
  2. 2. Sobre o que estamos falando? <ul><li>Milhares conexões simultâneas;
  3. 3. OLTP ;
  4. 4. Crescimentos de GBs ao dia;
  5. 5. LOCKs inferno ; </li></ul>
  6. 6. Sobre o que estamos falando? <ul><li>Milhares conexões simultâneas;
  7. 7. OLTP ;
  8. 8. Crescimentos de GBs ao dia;
  9. 9. LOCKs inferno ; </li></ul>
  10. 10. Problemas <ul><li>SO não trabalha bem com mais de 500 processos no SGDB (não importa se é Oracle, PostgreSQL, MySQL, Firebird, etc);
  11. 11. Hot Blocks (muitas pessoas querendo acesso ao mesmo bloco de dados);
  12. 12. Locks , Dead Locks , problemas de serialização de transações;
  13. 13. Gargalos em processador, memória, disco e rede, tudo ao mesmo tempo . </li></ul>
  14. 14. Diminua o volume de conexões <ul><ul><li>pgbouncer no modo transaction ;
  15. 15. Jamais abrir mais de uma conexão por client ;
  16. 16. Não usar muitas conexões em client/server . Utilize uma camada intermediária;
  17. 17. pgmemcache ;
  18. 18. ALTER ROLE role_name SET statement_timeout = xxx;
  19. 19. Morte às conexões em <IDLE>
  20. 20. Genocídio para <IDLE> In transaction ; </li></ul></ul>
  21. 21. Faça testes de carga <ul><li>Servidores de homologação deve possuir arquitetura idêntica a de produção e capacidade semelhante;
  22. 22. Faça testes que emulem a carga real da aplicação como um todo;
  23. 23. Faça o rollout da aplicação aumentando o número de conexões gradativamente ;
  24. 24. Coloque pontos de medição em vários pontos da aplicação;
  25. 25. Crie medições de referência ;
  26. 26. Monitore a aplicação, a rede e o SGDB;
  27. 27. Entenda a diferença entre saber e achar . </li></ul>
  28. 28. Acerte a sua modelagem <ul><ul><li>Modelagem de dados ruim pode levar anos para revelar um resultado ruim.
  29. 29. Leva horas para mostrar a catástrofe em alta concorrência; </li></ul></ul>
  30. 30. Acerte a sua modelagem <ul><ul><li>Desintegre todos os “ campos flex ” ;
  31. 31. Use hstore e vetores para dados pouco estruturados;
  32. 32. Acerte os tipos de dados ;
  33. 33. Valide os dados antes de gravar e limpe o que não é necessário;
  34. 34. Abomine os gatilhos
  35. 35. Não implemente pilhas e filas no banco de dados;
  36. 36. Chaves compostas facilitam o particionamento de tabelas; </li></ul></ul>
  37. 37. Hardware <ul><ul><li>CPU importa, número cores principalmente: número de conexões que você vai atender simultaneamente?
  38. 38. Memória importa: quanto de memória você vai disponibilizar por conexão ?
  39. 39. Disco importa, como sempre, particularmente para o pg_xlog: quantos COMMITs por segundo você pretende suportar?
  40. 40. Cache de gravação realmente importa ; </li></ul></ul>
  41. 41. SO (linux) <ul><ul><li>/etc/ sysctl.conf </li><ul><li>kernel.shmmax
  42. 42. semáforos
  43. 43. file-max
  44. 44. overcommit </li></ul><li>/etc/security/ limits.conf </li><ul><li>nproc
  45. 45. nofile </li></ul></ul></ul>
  46. 46. postgresql.conf <ul><li>Seja modesto com o shared_buffers ;
  47. 47. Ajuste cuidadosamente o autovacuum ;
  48. 48. Não dê muita memória por processo: </li><ul><li>temp_buffers < 16MB
  49. 49. work_mem < 16MB </li></ul><li>Seja generoso no checkpoint_segments mas cuidado com o tempo que o recover poderá levar.
  50. 50. Rotacione o seu log, ele poderá crescer muito rapidamente:
  51. 51. max_connections : faça o impossível e inimaginável para manter este número abaixo de 500. </li></ul>
  52. 52. pg_hba.conf <ul><ul><li>Limite ao máximo de onde suas conexões vem;
  53. 53. Limite ao máximo quais bases e quais usuários vão se conectar;
  54. 54. Rejeite usuários/grupos e redes desconhecidas; </li></ul></ul>
  55. 55. Ajustes em objetos <ul><li>Desligue ou ajuste individualmente o autovacuum em tabelas insanamente concorridas;
  56. 56. Diminua o fillfactor em tabelas que poderão crescer com UPDATEs;
  57. 57. Rode o ANALYZE ao término de cada processo de carga;
  58. 58. Agende o ANALYZE para tabelas onde você desligou o autovacuum em horários estratégicos;
  59. 59. Rode o VACUUM nas tabelas onde você desligou o autovacuum para uma janela de manutenção;
  60. 60. Aumente o cache de sequências muito utilizadas . </li></ul>
  61. 61. DML <ul><li>Ajuste parâmetros de desempenho por sessão no momento de cargas pesadas;
  62. 62. Exporte e importe com COPY ;
  63. 63. Se uma consulta retorna mais de 100 linhas , então isto deveria ser considerada uma exportação;
  64. 64. Não utilize PREPARE e EXECUTE sem critério um bom motivo para isso.
  65. 65. Nunca, jamais, em hipótese alguma, execute várias consultas idênticas , com apenas alguns parâmetros variando. Use subconsultas; </li></ul>
  66. 66. Em resumo <ul><li>Torne a sua regra de negócios mais flexível : Explique para quem vende a aplicação a diferença entre ter de mudar uma regra de negócio e não poder entregar o projeto todo;
  67. 67. Modele sua arquitetura pensando em alta concorrência, nem que você tenha que jogar uma boa parte do que já tem no lixo; </li></ul>
  68. 68. OBRIGADO Dúvidas, sugestões, correções, indignações e cervejas são bem vindas! Fábio Telles Rodriguez, Timbira: http://timbira.com.br SAVEPOINT: http://www.midstorm.org/~telles <ul><ul><li>e-mail: telles@timbira.com.br </li></ul></ul>

×