• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Postgres Tuning
 

Postgres Tuning

on

  • 737 views

Palestra sobre ajustes de desempenho no PostgreSQL ministrada em 03 de maio de 2013

Palestra sobre ajustes de desempenho no PostgreSQL ministrada em 03 de maio de 2013

Statistics

Views

Total Views
737
Views on SlideShare
737
Embed Views
0

Actions

Likes
1
Downloads
24
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Postgres Tuning Postgres Tuning Presentation Transcript

    • Postgres Tuningo elefante mais r´apido que um leopardoF´abio Telles RodriguezTimbira - A empresa brasileira de PostgreSQL03 de maio de 2013
    • AgendaSobre o que estamos falando?Ajustes iniciaisAjustes no SQLConsidera¸c˜oes finaisPerguntas
    • Sobre esta apresenta¸c˜aoesta apresenta¸c˜ao est´a dispon´ıvel em:http://www.timbira.com.br/materialesta apresenta¸c˜ao est´a sob licen¸ca Creative CommonsAtribui¸c˜ao 3.0 Brasil:http://creativecommons.org/licenses/by/3.0/br
    • Sobre o que estamos falando?Figura: Escolha dif´ıcil
    • Sobre o que estamos falando?Instala¸c˜oes el´etricas
    • Sobre o que estamos falando?Instala¸c˜oes el´etricasA maior preocupa¸c˜ao numa instala¸c˜ao el´etrica ´e sempre o calor;A corrente el´etrica gera calor;V´arios condutores em instalados juntos geram mais calor;As condi¸c˜oes de ventila¸c˜ao dificultam ou facilitam adissipa¸c˜ao do calor;As condi¸c˜oes atmosf´ericas ou a presen¸ca de outras fontes decalor devem ser levadas em considera¸c˜ao;Materiais inflam´aveis devem ser evitados.
    • Bancos de dadosA maior preocu¸c˜ao num banco de dados s˜ao os Discos;Antes de confirmar uma transa¸c˜ao (COMMIT) vocˆe devepersistir a informa¸c˜ao em disco;Discos s˜ao milhares de vezes mais lentos que a CPU e amem´oria;A lei de moore n˜ao se aplica aos discos;Grava¸c˜oes e leituras em discos s˜ao opera¸c˜oes seriais e n˜ao s˜aoparalelizadas;
    • DiscosFigura: Discos num Storage
    • Uso de discosUm UPDATE pode obrigar um registro a migrar de bloco seele n˜ao couber mais l´a;Ao atualizar um registro numa tabela, seus ´ındices tem de seratualizados tamb´em;Consultas pesadas que n˜ao cabem na mem´oria utilizam oTABLESPACE tempor´ario;Informa¸c˜oes de rollback s˜ao gravados para reverter umatrasa¸c˜ao;V´arias pessoas podem querer alterar os mesmos dados aomesmo tempo;
    • Log de transa¸c˜oes (WAL)Todo SGDB tenta guardar a maior parte poss´ıvel dos dadosem mem´oria;Toda vez que uma transa¸c˜ao ´e confirmada (COMMIT) umregistro no WAL ´e gravado;O WAL ´e o ”Write Ahead Log”grava os registrossequˆencialmente;de tempos em tempos os dados em mem´oria (dirty buffers)s˜ao gravados definitivamente nos datafiles (checkpoint);Se houver uma falha no SGDB o WAL ´e utilizado parareproduzir as tranza¸c˜oes em mem´oria que ainda n˜ao foramconsolidadas em disco;Informa¸c˜oes de rollback s˜ao gravados para reverter trasa¸c˜oesainda em mem´oria em caso de falha do SGDB;
    • Onde est´a o problema afinal?50% est˜ao em SQL mal escrito;20% est˜ao em modelagem de dados mal feita;10% est˜ao em ajustes ruins do SGDB;5% est˜ao em ajustes ruins do SO;5% est˜ao em hardware mal dimensionado;
    • AgendaSobre o que estamos falando?Ajustes iniciaisAjustes no SQLConsidera¸c˜oes finaisPerguntas
    • Hardware
    • HardwareUtilize um servidor dedicado. (VMs go home!);Utilize DISCOS dedicados (Tirem a m˜ao do meu storage!);Prioridade de gastos: discos, controladora de discos, mem´oria,processador;SSD SLC > SSD MLC > Fiber channel > SAS > SATA;Infiniband > Fiber channel > iSCSI;RAID 10 > RAID 1 > RAID 6 > RAID 5 > JBOD;Prefira controladoras com bastante cache, baterias externas esuportes a muitos discos;Prefira processadores com o melhor e maior cache poss´ıvel emuitos cores;
    • Sistema OperacionalPrefira sistemas UNIX: Linux, FreeBSD, OpenBSD, Solaris,etc;O melhor SO ´e aquele que sua equipe tem competˆencia paraoperar eficientemente;Sempre instale a vers˜ao em 64 bits do SO;Prioridade de gastos: discos, controladora de discos, mem´oria,processador;Prefira RAID por hardware e n˜ao por software;N˜ao use LVM;N˜ao instale softwares e servi¸cos desnecess´arios: interfacesgr´aficas, Samba, NFS, Apache, etc;
    • Particionamento de Discos (Linux)/boot (EXT4);raiz (EXT4);dados (RAID 10 ou RAID 1 + XFS ou EXT4 + noatime);pg xlog (RAID 10 ou RAID 1 + EXT2 + noatime ou EXT3 +noatime + writeback);pg log (EXT2 + noatime);tablespaces com ´ındices, tablespaces tempor´arios (RAID 0 +EXT2 + noatime);tablespaces com dados hist´oricos (RAID 5 + XFS ou EXT4 +noatime);backup e archives;
    • Ajustes no SO (Linux)/etc/sysctl.confkernel.shmmax (50% da RAM dispon´ıvel);Sem´aforos (para suportar um n´umero alto de conex˜oes);file-max;overcommit;/etc/security/limits.confnproc;nofile;/etc/fstabnoatime para os dados;noatime + writeback para o pg xlog;
    • Ajustes no PostgreSQLmax connections: O menor n´umero vi´avel;shared buffers: < 8GB ou 25% da RAM dispon´ıvel;maintence work mem: 75% do tamanho da maior tabela;checkpoint segments: entre 16 e 64;checkpoint timeout: entre 10min e 30min;
    • AgendaSobre o que estamos falando?Ajustes iniciaisAjustes no SQLConsidera¸c˜oes finaisPerguntas
    • Acerte a sua modelagemUse 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 tiposcompostos;Use ´ındices e gatilhos com sabedoria (teste e monitore o seuuso);Pilhas e filas n˜ao devem ficar no seu SGDB;
    • Escrevendo SQLJamais utilize uma fun¸c˜ao em PL para algo que um SQL puroconsegue fazer;COMMIT a cada X altera¸c˜oes. X > 100 e < 100K;Se uma consulta retorna mais de 100 registros, reveja a regrade neg´ocio;INSERT < INSERT multiplo < PREPARE e EXECUTE <COPY < INSERT ... SELECT;Aprenda a usar subconsultas e window functions e CommonTable Expression;Relat´orios pesados devem utilizar vis˜oes materializadas.
    • AgendaSobre o que estamos falando?Ajustes iniciaisAjustes no SQLConsidera¸c˜oes finaisPerguntas
    • TestesTeste as funcionalidades;Teste com volumes de dados o mais realistas poss´ıvel;Teste com carga de concorrˆencia o mais realista poss´ıvel;Aprenda a utilizar bem o EXPLAIN.
    • MonitoramentoMonitore 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 porferramentas 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!!!
    • Perguntas?F´abio Telles Rodrigueztelles@timbira.com.brhttp://www.timbira.com.br