fazendo uma manada de elefantes passar por baixo da porta
DESCRIPTION
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.TRANSCRIPT
por Fábio Telles4 de novembro de 2011
Fazendo uma manada de elefantes passar
debaixo da porta
por Fábio Telles4 de novembro de 2011
Sobre o que estamos falando?Milhares conexões simultâneas;OLTP;Crescimentos de GBs ao dia;LOCKs inferno;
por Fábio Telles4 de novembro de 2011
Sobre o que estamos falando?Milhares conexões simultâneas;OLTP;Crescimentos de GBs ao dia;LOCKs inferno;
por Fábio Telles4 de novembro de 2011
Problemas
SO não trabalha bem com mais de 500 processos no SGDB (não importa se é Oracle, PostgreSQL, MySQL, Firebird, etc);
Hot Blocks (muitas pessoas querendo acesso ao mesmo bloco de dados);
Locks, Dead Locks, problemas de serialização de transações;
Gargalos em processador, memória, disco e rede, tudo ao mesmo tempo.
por Fábio Telles4 de novembro de 2011
Diminua o volume de conexões
pgbouncer no modo transaction;Jamais abrir mais de uma conexão por client;Não usar muitas conexões em client/server. Utilize uma camada intermediária;pgmemcache;ALTER ROLE role_name SET statement_timeout = xxx;Morte às conexões em <IDLE>Genocídio para <IDLE> In transaction;
por Fábio Telles4 de novembro de 2011
Faça testes de carga
Servidores de homologação deve possuir arquitetura idêntica a de produção e capacidade semelhante;
Faça testes que emulem a carga real da aplicação como um todo;
Faça o rollout da aplicação aumentando o número de conexões gradativamente;
Coloque pontos de medição em vários pontos da aplicação; Crie medições de referência; Monitore a aplicação, a rede e o SGDB; Entenda a diferença entre saber e achar.
por Fábio Telles4 de novembro de 2011
Acerte a sua modelagem
Modelagem de dados ruim pode levar anos para revelar um resultado ruim.
Leva horas para mostrar a catástrofe em alta concorrência;
por Fábio Telles4 de novembro de 2011
Acerte a sua modelagem
Desintegre todos os “campos flex”;Use hstore e vetores para dados pouco estruturados;Acerte os tipos de dados;Valide os dados antes de gravar e limpe o que não é necessário;Abomine os gatilhosNão implemente pilhas e filas no banco de dados;Chaves compostas facilitam o particionamento de tabelas;
por Fábio Telles4 de novembro de 2011
Hardware
CPU importa, número cores principalmente: número de conexões que você vai atender simultaneamente?Memória importa: quanto de memória você vai disponibilizar por conexão?Disco importa, como sempre, particularmente para o pg_xlog: quantos COMMITs por segundo você pretende suportar?Cache de gravação realmente importa;
por Fábio Telles4 de novembro de 2011
SO (linux)
/etc/sysctl.confkernel.shmmaxsemáforosfile-max overcommit/etc/security/limits.conf nproc nofile
por Fábio Telles4 de novembro de 2011
postgresql.conf Seja modesto com o shared_buffers; Ajuste cuidadosamente o autovacuum; Não dê muita memória por processo: temp_buffers < 16MBwork_mem < 16MB Seja generoso no checkpoint_segments mas cuidado com o tempo que o recover poderá levar. Rotacione o seu log, ele poderá crescer muito rapidamente: max_connections: faça o impossível e inimaginável para manter este número abaixo de 500.
por Fábio Telles4 de novembro de 2011
pg_hba.conf
Limite ao máximo de onde suas conexões vem;Limite ao máximo quais bases e quais usuários vão se conectar;Rejeite usuários/grupos e redes desconhecidas;
por Fábio Telles4 de novembro de 2011
Ajustes em objetos
Desligue ou ajuste individualmente o autovacuum em tabelas insanamente concorridas; Diminua o fillfactor em tabelas que poderão crescer com UPDATEs; Rode o ANALYZE ao término de cada processo de carga; Agende o ANALYZE para tabelas onde você desligou o autovacuum em horários estratégicos; Rode o VACUUM nas tabelas onde você desligou o autovacuum para uma janela de manutenção; Aumente o cache de sequências muito utilizadas.
por Fábio Telles4 de novembro de 2011
DML
Ajuste parâmetros de desempenho por sessão no momento de cargas pesadas; Exporte e importe com COPY; Se uma consulta retorna mais de 100 linhas, então isto deveria ser considerada uma exportação;Não utilize PREPARE e EXECUTE sem critério um bom motivo para isso. Nunca, jamais, em hipótese alguma, execute várias consultas idênticas, com apenas alguns parâmetros variando. Use subconsultas;
por Fábio Telles4 de novembro de 2011
Em resumo
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; Modele sua arquitetura pensando em alta concorrência, nem que você tenha que jogar uma boa parte do que já tem no lixo;
por Fábio Telles4 de novembro de 2011
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 email: [email protected]