Alta concorrˆ encia com PostgreSQL ou Fazendo uma manada de elefantes passar debaixo da porta F´ abio Telles Rodriguez Timbira - A empresa brasileira de PostgreSQL 09 de novembro de 2012
Sobre esta apresenta¸ c˜ ao esta apresenta¸ c˜ ao est´ a dispon´ ıvel em: http://www.timbira.com.br/material esta apresenta¸ c˜ ao est´ a sob licen¸ ca Creative Commons Atribui¸ c˜ ao 3.0 Brasil: http://creativecommons.org/licenses/by/3.0/br
Sobre o que estamos falando? Aplica¸ c˜ oes OLTP com alta concorrˆ encia: Milhares de conex˜ oes simultˆ aneas; V´ arios usu´ arios realizando grava¸ c˜ oes nas mesmas tabelas; V´ arias usu´ arios consultando informa¸ c˜ oes que acabaram de ser gravadas; Cada usu´ ario deve ser atendido em tempo h´ abil; Crescimento de v´ arios GBs por dia.
Tratamento Multi Documentos - TMD Tratamento de imagens descentralizado em ambiente bancario: Crescimento de 5GB a 20GB por dia; At´ e 2 milh˜ oes documentos tratados por dia; Mais de 5 mil agˆ encias com 10 mil esta¸ c˜ oes de captura. Pool de 25 servidores com complementa¸ c˜ ao autom´ atica; Mais de 500 esta¸ c˜ oes de complementa¸ c˜ ao manual; Centenas de regras de neg´ ocio aplicadas para diversos tipos de documento em diversas etapas (workflow); Troca de informa¸ c˜ oes em lote com Mainframe; Troca de informa¸ c˜ oes em XML com outros sistemas legados; Exporta¸ c˜ ao de arquivos de sa´ ıda. TUDO AO MESMO TEMPO, com janela de 6 horas de processamento.
Gargalo de CPU SO n˜ ao trabalha bem com mais de 700 processos simultˆ aneos; O custo para gerenciar a fila de espera s´ o aumenta o problema; Cada conex˜ ao precisa de mem´ oria, keep alive pela rede e semaforiza¸ c˜ ao; O n´ umero de conex˜ oes ativas no SGDB deve ficar na ´ ordem de 2 para cada core; Aplica¸ c˜ oes server podem utilizar conex˜ oes persistentes... ... as aplica¸ c˜ oes client N˜ AO;
Problemas com a modelagem Modelagem de dados ruim pode levar anos para revelar um resultado ruim. Leva horas para mostrar a cat´ astrofe em alta concorrˆ encia;
Controlando o n´ umero de conex˜ oes PGBouncer: 1 Pool de conex˜ oes para transa¸ c˜ oes no modo transaction; 1 Pool de conex˜ oes para consultas no modo statement; Aumento na eficiencia do processador, fila de espera das transa¸ c˜ oes diminui; PGmemcache Replicas de dados do PostgreSQL para SQLite nas esta¸ c˜ oes utiliza memcache; Um gatilho nas tabelas replicadas atualiza o n´ umero de vers˜ ao do cache; Ao solicitar uma r´ eplica, a esta¸ c˜ ao compara a sua vers˜ ao da tabela com a vers˜ ao do cache; Poderia ser implementado com Listem / Notify
Locks S´ o abra uma transa¸ c˜ ao, se realmente precisar; Saiba quando abrir e quando fechar uma transa¸ c˜ ao; N˜ ao se perca na aplica¸ c˜ ao; Se abrir, feche logo. N˜ ao espere eventos for a do SGDB para fechar sua transa¸ c˜ ao; N˜ ao utilize SELECT ... FOR UPDATE; N˜ ao utilize LOCKs expl´ ıcitos. Tire proveito do MVCC; DEAD LOCK s˜ ao problemas de l´ ogica da aplica¸ c˜ ao. Altere a l´ ogica dela;
Ajustes de Hardware CPU r´ apida ´ e menos importante que ter muitos cores; Muita mem´ oria RAM para manter um n´ umer alto de conex˜ oes; Use cache de disco para suportar um grande volume de grava¸ c˜ oes concorrentes; Discos r´ apidos e separados para o pg xlog ´ e imprecind´ ıvel;
Ajustes no SO (Linux) /etc/sysctl.conf kernel.shmmax (25% da RAM dispon´ ıvel) Sem´ aforos (para suportar um n´ umero alto de conex˜ oes) file-max overcommit /etc/security/limits.conf nproc nofile /etc/fstab noatime para os dados noatime + writeback para o pg xlog
Ajustes no PostgreSQL max connections O menor n´ umero vi´ avel; Fa¸ ca o poss´ ıvel para diminuir este valor para menos de 500; pg hba.conf Limite ao m´ aximo a origem das suas conex˜ oes; Limite os usu´ arios e bases que eles v˜ ao se conectar; Rejeite usu´ arios, grupos e redes desconhecidos;
Ajustes no PostgreSQL shared buffers < 8GB ou 20% da RAM dispon´ ıvel (o que for maior); autovacuum em tabelas que sofrem cargas pesadas em lote, desligue; Mem´ oria por processo temp buffer < 16MB work mem < 16MB Ajuste individualmente conex˜ oes espec´ ıficas; checkpoint segments Aumente para pelo menos 16 Limite de acordo com tempo que o recover pode levar
Acerte a sua modelagem Use o tipo de dados certo para a tarefa certa; Use chaves naturais; N˜ ao use campos flex; Para dados n˜ ao estruturados, vocˆ e tem hstore, vetores e tipos compostos; Use ´ ındices e gatilhos com sabedoria (teste e monitore o seu uso); Pilhas e filas n˜ ao devem ficar no seu SGDB;
Escrevendo SQL Jamais utilize uma fun¸ c˜ ao em PL para algo que um SQL puro consegue fazer; COMMIT a cada X altera¸ c˜ oes. X > 100 e < 100K; Se uma consulta retorna mais de 100 registros, reveja a regra de neg´ ocio; INSERT < INSERT multiplo < PREPARE e EXECUTE < COPY < INSERT ... SELECT Aprenda a usar subconsultas e window functions e Common Table Expression; Relat´ orios pesados devem utilizar vis˜ oes materializadas.
Rollout Como testes com volume de dados e concorrˆ encia nunca s˜ ao bons... Fa¸ ca o deploy de poucas funcionalidades por vˆ ez; Adicione novos usu´ arios aos poucos; Esteja preparado para o caos durante o rollout; N˜ ao tente matar mais de um le˜ ao por dia; O rollout de uma ´ unica parte do sistema pode levar meses;
Monitoramento Monitore o SO, o PostgreSQL, a aplica¸ c˜ ao; Gere logs que mostrem a opera¸ c˜ ao e a dura¸ c˜ ao de cada a¸ c˜ ao; Gere logs em formatos que possam ser manipulados por ferramentas automatizadas; Aprenda a configurar o log do PostgreSQL e o PGBadger; Fa¸ ca coletas peri´ odicas e armazene tudo em um local central; Crie baselines e compare sempre com elas;
Para os DBAs... Durma bem antes de um novo deploy. Tire uns dias de folga; N˜ ao deixe de tomar cerveja com os amigos... Pratique exerc´ ıcios f´ ısicos regularmente!!!
fabiotr
zakky21
yonetty
katsu8686
aridlehoover
.jpg){kind=avatar}
yumnumm
texmeijin
seike460
nrslib
toricky6
yusukebe
kishida
kasacchiful
chriscoyier
morganepeng
zakiyama
scottboms
malarkey
tammielis
stephaniewalter
jlugia
caitiem20
akosma
3n