fazendo uma manada de elefantes passar por baixo da porta

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 e­mail: telles@timbira.com.br