Alta concorrencia com PostgreSQLou Fazendo uma manada de elefantes passar debaixo da porta

Fabio Telles Rodriguez

Timbira - A empresa brasileira de PostgreSQL

09 de novembro de 2012

Agenda

Sobre o que estamos falando?

Possıveis solucoes

Consideracoes finais

Perguntas

Sobre esta apresentacao

I esta apresentacao esta disponıvel em:http://www.timbira.com.br/material

I esta apresentacao esta sob licenca Creative CommonsAtribuicao 3.0 Brasil :http://creativecommons.org/licenses/by/3.0/br

Sobre o que estamos falando?

Figura: Metro - SP / Estacao Se

Sobre o que estamos falando?

Aplicacoes OLTP com alta concorrencia:

I Milhares de conexoes simultaneas;

I Varios usuarios realizando gravacoes nas mesmas tabelas;

I Varias usuarios consultando informacoes que acabaram de sergravadas;

I Cada usuario deve ser atendido em tempo habil;

I Crescimento de varios GBs por dia.

Tratamento Multi Documentos - TMD

I Tratamento de imagens descentralizado em ambientebancario:

I Crescimento de 5GB a 20GB por dia;

I Ate 2 milhoes documentos tratados por dia;

I Mais de 5 mil agencias com 10 mil estacoes de captura.

I Pool de 25 servidores com complementacao automatica;

I Mais de 500 estacoes de complementacao manual;

I Centenas de regras de negocio aplicadas para diversos tipos dedocumento em diversas etapas (workflow);

I Troca de informacoes em lote com Mainframe;

I Troca de informacoes em XML com outros sistemas legados;

I Exportacao de arquivos de saıda.

I TUDO AO MESMO TEMPO, com janela de 6 horas deprocessamento.

Gargalo de CPU

Figura: Trem em Mulan - Paquistao

Gargalo de CPU

I SO nao trabalha bem com mais de 700 processos simultaneos;

I O custo para gerenciar a fila de espera so aumenta oproblema;

I Cada conexao precisa de memoria, keep alive pela rede esemaforizacao;

I O numero de conexoes ativas no SGDB deve ficar na ordemde 2 para cada core;

I Aplicacoes server podem utilizar conexoes persistentes...

I ... as aplicacoes client NAO;

Lock Inferno

Figura: Cruzamento das Avenidas Faria Lima com a Juscelino Kubitschek

Problemas com a modelagem

I Modelagem de dados ruim pode levar anos para revelar umresultado ruim.

I Leva horas para mostrar a catastrofe em alta concorrencia;

Agenda

Sobre o que estamos falando?

Possıveis solucoes

Consideracoes finais

Perguntas

Controlando o numero de conexoes

PGBouncer:

I 1 Pool de conexoes para transacoes no modo transaction;

I 1 Pool de conexoes para consultas no modo statement;

I Aumento na eficiencia do processador, fila de espera dastransacoes diminui;

PGmemcache

I Replicas de dados do PostgreSQL para SQLite nas estacoesutiliza memcache;

I Um gatilho nas tabelas replicadas atualiza o numero de versaodo cache;

I Ao solicitar uma replica, a estacao compara a sua versao databela com a versao do cache;

I Poderia ser implementado com Listem / Notify

Locks

I So abra uma transacao, se realmente precisar;

I Saiba quando abrir e quando fechar uma transacao; Nao seperca na aplicacao;

I Se abrir, feche logo. Nao espere eventos for a do SGDB parafechar sua transacao;

I Nao utilize SELECT ... FOR UPDATE;

I Nao utilize LOCKs explıcitos. Tire proveito do MVCC;

I DEAD LOCK sao problemas de logica da aplicacao. Altere alogica dela;

Ajustes de Hardware

I CPU rapida e menos importante que ter muitos cores;

I Muita memoria RAM para manter um numer alto deconexoes;

I Use cache de disco para suportar um grande volume degravacoes concorrentes;

I Discos rapidos e separados para o pg xlog e imprecindıvel;

Ajustes no SO (Linux)

/etc/sysctl.conf

I kernel.shmmax (25% da RAM disponıvel)

I Semaforos (para suportar um numero alto de conexoes)

I file-max

I overcommit

/etc/security/limits.conf

I nproc

I nofile

/etc/fstab

I noatime para os dados

I noatime + writeback para o pg xlog

Ajustes no PostgreSQL

max connections

I O menor numero viavel;

I Faca o possıvel para diminuir este valor para menos de 500;

pg hba.conf

I Limite ao maximo a origem das suas conexoes;

I Limite os usuarios e bases que eles vao se conectar;

I Rejeite usuarios, grupos e redes desconhecidos;

Ajustes no PostgreSQL

shared buffers

I < 8GB ou 20% da RAM disponıvel (o que for maior);

autovacuum

I em tabelas que sofrem cargas pesadas em lote, desligue;

Memoria por processo

I temp buffer < 16MB

I work mem < 16MB

I Ajuste individualmente conexoes especıficas;

checkpoint segments

I Aumente para pelo menos 16

I Limite de acordo com tempo que o recover pode levar

Acerte a sua modelagem

I Use o tipo de dados certo para a tarefa certa;

I Use chaves naturais;

I Nao use campos flex;

I Para dados nao estruturados, voce tem hstore, vetores e tiposcompostos;

I Use ındices e gatilhos com sabedoria (teste e monitore o seuuso);

I Pilhas e filas nao devem ficar no seu SGDB;

Escrevendo SQL

I Jamais utilize uma funcao em PL para algo que um SQL puroconsegue fazer;

I COMMIT a cada X alteracoes. X > 100 e < 100K;

I Se uma consulta retorna mais de 100 registros, reveja a regrade negocio;

I INSERT < INSERT multiplo < PREPARE e EXECUTE <COPY < INSERT ... SELECT

I Aprenda a usar subconsultas e window functions e CommonTable Expression;

I Relatorios pesados devem utilizar visoes materializadas.

Agenda

Sobre o que estamos falando?

Possıveis solucoes

Consideracoes finais

Perguntas

Testes

I Teste as funcionalidades

I Teste com volumes de dados o mais realistas possıvel

I Teste com carga de concorrencia o mais realista possıvel

Rollout

Como testes com volume de dados e concorrencia nunca saobons...

I Faca o deploy de poucas funcionalidades por vez;

I Adicione novos usuarios aos poucos;

I Esteja preparado para o caos durante o rollout;

I Nao tente matar mais de um leao por dia;

I O rollout de uma unica parte do sistema pode levar meses;

Monitoramento

I Monitore o SO, o PostgreSQL, a aplicacao;

I Gere logs que mostrem a operacao e a duracao de cada acao;

I Gere logs em formatos que possam ser manipulados porferramentas automatizadas;

I Aprenda a configurar o log do PostgreSQL e o PGBadger;

I Faca coletas periodicas e armazene tudo em um local central;

I Crie baselines e compare sempre com elas;

Para os DBAs...

I Durma bem antes de um novo deploy. Tire uns dias de folga;

I Nao deixe de tomar cerveja com os amigos...

I Pratique exercıcios fısicos regularmente!!!

Perguntas

?Fabio Telles Rodrigueztelles@timbira.com.br

http://www.timbira.com.br