PostgreSQL tuning - Prelúdio

<p>Normalmente ao pensar em melhorar a performance do banco de dados, muitos esquecem de modificar alguns parâmetros e configurações do Sistema Operacional e outras coisas relacionadas a infraestrutura de TI. Não dar a atenção devida para essas coisas é que elas podem impactar o desempenho do banco de dados e você estar tão focado em melhorar o banco de dados que não considera-os como a causa raiz.</p> <p>Bom, então a idéia aqui é ser uma etapa prévia antes de mexer nas configurações do <a href="http://www.postgresql.org/">PostgreSQL</a>, portanto considere como um ponto de partida. Cada aplicação e arquitetura terá uma configuração específica do PostgreSQL para que tenho o melhor desempenho possível.</p> <h3>Adote um método para fazer os ajustes de performance.</h3> <p>Infelizmente não existes muitos números mágicos (ok, existe alguns números mágicos mas não é caso neste momento). Para fazer os ajustes para melhorar o desempenho do PostgreSQL e consequetemente da aplicação é necessário fazer vários testes em muitas variáveis. Fazer alterações em muitas variáveis ao mesmo tempo pode levar muito mais tempo do que fazer alterações em poucas ou uma variável e observar se obteve ganho de performance ou não. Portanto, adote uma metodologia, faça uma mudança por vez e teste! Anote os resultados, faça outra alteração e compare coms os resultados anteriores. Assim poderá comparar e verificar quais são os melhores ajustes em determinados cenários que imaginar que a aplicação faz.</p> <p>Vale qualquer forma de registro, até papel de padaria!</p> <h3>Armazenamento</h3> <p>Tão ou mais importante que ter uma servidor com uma capacidade tão grande de processamento é ter a parte de armazenamento (discos/storages) bem plenajada. É muito comum usar Storages com um único Array e compartilho entre as diversas aplicacṍes da instituição.</p> <p>Como aparentemente o Storage tem I/O infinito, geralmente é relegado algum planejamento de como as aplicações ou base de dados irão ocupá-lo. Em situações de grande uso de I/O (escrita ou leitura) é importante criar grupos de discos (arrays) considerando usar as partes mais rápidas do Storage para as bases ou operações críticas e com conexões de fibras dedicadas para o servidor PostgreSQL.</p> <p> O Telles escreveu um <a href="http://savepoint.blog.br/postgresql-discos-cia/">bom texto</a> sobre discos, recomendada a leitura.</p> <p>Considere sempre usar &#8220;canais&#8221; dedicados de comunicação entre o servidor do banco de dados e o armazenamento. Exemplo: Caso esteja usando um sistema de arquivo de rede (<a href="http://pt.wikipedia.org/wiki/Network-Attached_Storage">NAS</a>) para o banco de dados, considere segregar em uma rede dedicada à eles para que não haja concorrência de tráfego de rede com outros serviços e/ou aplicações. Caso esteja usando comunicação via Fiber Channel (<a href="http://pt.wikipedia.org/wiki/Rede_de_%C3%A1rea_de_armazenamento">SAN</a>), tente deixar as conexões físicas dedicadas entre o servidor de banco de dados, switch fiber channel e o storage.</p> <p>Armazenamento de banco de dados é um tema tão vasto que facilmente poderia ser um Livro de centenas de páginas mas por enquanto ficamos por aqui&#8230;</p> <h3>Habilitar ou não o HyperThreading</h3> <p> Para o PostgreSQL não faz diferença se o <a href="http://pt.wikipedia.org/wiki/Hyper-threading">HyperThreading</a> habilitado ou não, ele usará o número máximo de processadores que o Sistema Operacional disponibilizar.</p> <h3>Sistema Operacional</h3> <p>É simples, use Unix/Linux e que seja 64 bits. Entendo que exista questões de usar um Sistema Operacional &#8220;homologado&#8221; para o servidor ou Storage mas se quer o máximo de performance seria melhor usar <a href="http://www.centos.org/">CentOS</a> ou [Debian<a href="http://www.debian.org/">7</a> ou mesmo um <a href="https://www.archlinux.org/">ArchLinux</a>.</p> <p>Antes do tuning do banco de dados, tuning do Sistema Operacional.</p> <p>Isso é coisa básica mas extremamente importante, afinal é impossível aumentar o<em>Shared Buffer</em> do PostgreSQL sem aumentar a memória compartilhada do Linux. Considere aumentar a memória compartilhada (<em>Shared Memory</em>), <em>semáforos</em>, buffers de rede, scheduler I/O, etc.</p> <h4>Memória compartilhada (shared memory)</h4> <p>Mais ou menos 25% da memória total é a resposta padrão mas pode ser interessante iniciar os ajustes com valor menor. Algo entre 15% e 20% do total disponível da RAM e depois ajustar para um valor maior. Exemplo para 10GB:</p> <pre> #sysctl -w kernel.shmmax=109951162777 </pre> <h4>Usando Swap somente em último caso</h4> <p> O Kernel Linux por padrão usa a memória <a href="http://pt.wikipedia.org/wiki/Mem%C3%B3ria_virtual">Swap</a> (&#8220;extensão&#8221; da memória RAM na HD, é muito) antes mesmo de esgotar o espaço livre da memória RAM. Para utilizar a Swap somente em último caso:</p> <pre> #sysctl -w vm.swappiness=0 </pre> <h3>Rede</h3> <p> Supondo que o servidor tem placas de rede de 10GBits/s.</p> <pre> #systcl -w net.core.rmem_default = 8388608 #systcl -w net.core.rmem_max = 8388608 #systcl -w net.core.wmem_default = 8388608 #systcl -w net.core.wmem_max = 8388608 #systcl -w net.core.netdev_max_backlog = 10000 </pre> <h4>Ajustes na pilha de rede.</h4> <pre> #systcl -w net.ipv4.tcp_max_syn_backlog = 40000 #systcl -w net.core.somaxconn=4000 #systcl -w net.ipv4.tcp_timestamps = 0 #systcl -w net.ipv4.tcp_sack = 1 #systcl -w net.ipv4.tcp_window_scaling = 1 #systcl -w net.ipv4.tcp_fin_timeout = 15 #systcl -w net.ipv4.tcp_keepalive_intvl = 30 #systcl -w net.ipv4.tcp_tw_reuse = 1 </pre> <h3>Scheduler I/O</h3> <p>O Kernel Linux tem vários tipos de scheduler, por padrão atualmente é o <a href="http://en.wikipedia.org/wiki/CFQ">CFQ</a> mas para operações intensivas de I/O o <a href="http://en.wikipedia.org/wiki/Deadline_scheduler">Deadline</a> tem um resultado melhor.</p> <pre> #echo deadline > /sys/block/sda/queue/scheduler </pre> <h3>Limite de Arquivos Abertos (Open Files Limit)</h3> <p> Acontece com muita frequencia alterar a configuração do Linux, servidor de aplicação, algoritimos, banco de dados e esquecer de alterar o &#8220;Limite de Arquivos Abertos&#8221;. Não alterá-lo significa numa analogia grosseira dizer que &#8220;você está andando de Porche com o freio de mão puxado.&#8221;. Este item é importantíssimo porque se estiver com valores relativamente baixos, nenhuma ferramenta de monitoramento irá detectar isso como um gargalo de desempenho.</p> <p>Para configurar o usuário <strong>postgres</strong> com um limite maior:</p> <p>Edite o <em>/etc/pam.d/common-session</em>, acrescente, salve e feche o arquivo.</p> <pre> session required pam_limits.so </pre> <p>Edite o <em>/etc/security/limits.conf</em> e acrescente as linhas abaixo:</p> <pre> * soft nofile 65536 * hard nofile 65536 </pre> <p>Lembre-se de salvar, fechar o arquivo e reinicar para que as alterações tenham efeito. Para saber mais, vale ler a <a href="http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/">documentação</a> do Riak sobre isso.</p> <h3>Sistema de Arquivo</h3> <p>Esse é um difícil dizer qual é a melhor opção, eu não conheço benchmarks recentes mas o benchmark que fiz algum tempo atrás apontou que para bases de dados pequenas e de pouco usuários simultâneos é melhor usar <a href="http://pt.wikipedia.org/wiki/Ext4">Ext4</a>. No cenário de base de dados grandes e muitos usuários simultâneos o <a href="http://pt.wikipedia.org/wiki/XFS">XFS</a> tem uma performance melhor.</p> <p>Também é imporante fazer outros ajustes como modificar a montagem dos discos para desconsiderar o timestamp da criação/edição de arquivos e diretórios. Exemplo de entrada no <em>/etc/fstab</em>:</p> <pre> [...] /dev/sdd1 /opt/pg/9.3/db xfs defaults,noatime,nodiratime,nodev 0 0 [...] </pre> <p>Se você tiver alguma informação do <a href="https://btrfs.wiki.kernel.org/index.php/Main_Page">Brtfs</a>, Ext4 e XFS com benchamrks mais novos, comente aí. :D</p> <h3>Conclusão</h3> <p>Pensar em tuning de banco de dados sem considerar os ajustes de desempenho de toda arquitetura envolvida é como colocar um motor de Porsche num Fusca. Tuning é uma tarefa contínua enquanto a aplicação existir. Existe bons textos sobre o tema, recomendo a leitura de alguns:</p> <ul> <li><a href="http://www.redbooks.ibm.com/abstracts/redp4285.html">Red book Linux Performance and Tuning Guidelines</a></li> </ul> <p>Livro antigo mas com informações preciosas.</p> <ul> <li><a href="http://docs.basho.com/riak/latest/cookbooks/Linux-Performance-Tuning/">Linux Performance Tuning - Riak - Basho</a></li> </ul> <p>Bem didádico, as dicas estão aplicadas para o Riak mas vale como referência.</p> <ul> <li><a href="http://docs.neo4j.org/chunked/stable/linux-performance-guide.html">Linux Performance Guide - Neo4J</a></li> </ul> <p>Também bem didático mas aplicado para o Neo4J.</p> <p>Neste texto tem uma visão bem particular, se tiver alguma sugestão, crítica ou correção. Faça! :)</p>