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>

Fazendo seu site voar com Pagespeed

Front End Optimization (FEO) é um dos buzzwords mais comentados nos últimos tempos. São vários métodos/técnicas que permite ao navegador carregar mais rapidamente as páginas HTML.

De certa foram, FEO é uma área parecida com segurança para uma equipe de desenvolvimento. Exige muito tempo e atenção aos detalhes mas se incorporado, permite ganhos visíveis de audiência, conversão de vendas, etc.

Muito avaliam que investir em FEO é um desperdício porque o mundo (em sua maioria) está indo em direção aos aplicativos nativos das plataformas móvel (mobile) ao invés de concentrar todos os esforços em aplicações base HTML(5). Fato ou não as duas formas coexistirão mas isso fica para um próximo texto. Voltando ao assunto título deste texto: Pagespeed

Ele é um serviço de otimização de sites alterando as páginas de um site para obter a melhor performance possível usando coisas como: CSS sprites, otimização de imagens, defer de javascript, minify, etc. Se você não quiser usar o serviço e usá-lo diretamente no seu servidor web pode pois o código do módulo é Código Aberto (Apache License). A restrição é que é que o módulo está disponível para Nginx e Apache.

Os testes foram realizados usando Apache e Debian Wheezy e meu blog com Octopress. Na página do módulo tem os detalhes da instalação, basicamente é baixar o pacote .deb e instalá-lo.

#wget -c https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb
#dpkg -i mod-pagespeed-stable_current_amd64.deb

Por padrão o módulo não é ativo, pode fazê-lo diretamente no VirtualHost ou a ativar para todos os existentes. Mas cuidado, não vá alterar habilitar para todos os sites pois algumas alterações podem quebrar o layout do site. Faça uma homologação antes. Para este teste foi alterado o pagespeed.conf em /etc/apache2/mods-avaliable/pagespeed.conf de Off para On e depois ativado com a2enmod.

#vi /etc/apache2/mods-available/pagespeed.conf

    # Turn on mod_pagespeed. To completely disable mod_pagespeed, you
    # can set this to "off".
    ModPagespeed on
[...]

#a2enmod pagespeed

A documentação é bem detalhada e recomendo uma leitura dela. Se quiser ver como um filtro é aplicado, pode ver no Modpagespeed. Os detalhes de cada uma pode acessar aqui.

#vi /etc/apache2/site-avaliable/www.fernandoike.com

[...]
        ModPagespeedEnableFilters combine_css
        ModPagespeedEnableFilters combine_javascript
        ModPagespeedEnableFilters rewrite_css,sprite_images
        ModPagespeedEnableFilters rewrite_javascript
        ModPagespeedEnableFilters inline_css
        ModPagespeedEnableFilters inline_javascript
        ModPagespeedEnableFilters rewrite_images
        ModPagespeedEnableFilters insert_img_dimensions
        ModPagespeedEnableFilters remove_comments
        ModPagespeedEnableFilters extend_cache
        ModPagespeedEnableFilters remove_quotes
        ModPagespeedEnableFilters defer_javascript
        ModPagespeedEnableFilters flatten_css_imports
        ModPagespeedEnableFilters lazyload_images
        ModPagespeedEnableFilters recompress_images
        ModPagespeedEnableFilters move_css_above_scripts
        ModPagespeedDomain http://www.fernandoike.com

[...]

Feito as configurações, vamos aos resultados. Eles foram feito com o
Webpagetest (WPT) e todos baseados no Firefox e uma conexão de 5 Mbit/s.

Teste feito em Virgínia nos EUA sem PageSpeed.

O Document Complete (tempo que o navegador levou para deixar a página “pronta” para usar) ou Onload foi entregue me 3,972 segundos, 56 requisições e 1.535 Kbytes de tamanho. Um bom resultado para um blog.

Teste feito em Virgínia nos EUA com PageSpeed.

Teste feito em São Paulo sem PageSpeed.

Teste feito em São Paulo com PageSpeed.

Tabulando para facilitar a comparação:

EUA

Brasil

O resultado com PageSpeed em Virgínia teve uma redução drástica no tamanho da página, em torno de 42%, 39% no Doc Complete e 30% em requisições.

Agora em São Paulo as reduções foram: 39% no tamanho da página, 26% no Doc Complete e 22% de requisições.

Fazendo configurações básicas dos filtros do PageSpeed consegue uma boa otimização. Considerando o baixo esforço para implementá-lo, é altamente recomendável mas é importante homologar as alterações feitas por ele porque
pode quebrar o layout das páginas.

A distância geográfica impacta na experiência do usuário, como o servidor do teste está em Dallas e Virgínia é mais perto que São Paulo, é perceptível o impacto no tempo do Doc Complete ao comparar as duas localidades. Existem maneiras de melhorar o resultado de São Paulo se usar uma CDN mas isso fica para outro texto.

Estou um pouco mais ágil: Scrum

Há um pouco mais de um ano atrás eu decidi que iria mudar o foco da minha carreira profissional, desde então tenho estudado e aplicado em alguns projetos pessoais que tem gerado boas surpresas.

Essa aqui abaixo é uma delas. :)

Claro que um certificado com esse não é que define se alguém é ou poderá ser um bom ScrumMaster. Venho aplicando Scrum em alguns projetos já algum tempo, mas agora posso dizer que “oficialmente” sou um ScrumMaster.

Instalando LOIC no Debian

Nos últimos meses tem ocorrido muitas solicitações de clientes para fazer testes de carga ou segurança usando LOIC. LOIC (Low Orbit Ion Cannon) é um software desenvolvido em C# e ele tem o objetivo de fazer ataques de negação de serviço (Denial-of-Service) ou ataques de negação de serviço dstribuído (Distributed Denial-of-Service).

O LOIC possibilita ataques usando TCP, UDP ou HTTP, ele ou alguns derivados dele (como JS LOIC) são muito usados pela anonymous como represália ou protesto contra algum site de empresa, governo ou instituição política.

Bom, o LOIC para meu trabalho nesses clientes tem a função de avaliar a capacidade de contenção/mitigação de ataques de DOS/DDOS. Geralmente avalia-se se o Firewall, IPS (Intrusion Prevention System), WAF (Web Application Firewall), etc. conseguem conter esse tipo de ataque. Caso seja identificado que não, é entregue um relatório com propostas de mudança na infraestrutura do cliente.

Ops… Voltando ao assunto título deste artigo, a instalação no Linux é possível de duas maneiras: instalando WINEe ou instalando o MONO. No meu caso instalei o MONO e minha distribuição é o Debian.

O procedimento é relativamente simples:

#aptitude install mono-complete

Para baixar o LOIC pode fazer acessando a página do projeto no Sourceforge

Após baixar, descompacte e execute o LOIC usando o MONO.

$unzip LOIC-1.0.7.42-binary.zip
$mono LOIC.exe

Como você pode ler, a instalação é simples. O LOIC também não é complexo como pode ver no screenshot do Debian instalado no meu computador.

Hangout com Bruno Domingues adiado...

Muito estranho, muito estranho mesmo… :)

Toda vez que tentamos fazer o Hangout com o Bruno Domingues da Intel acontece alguma problema. Ele teve um probleminha no meio da transmissão do hangout e tivemos que adiar novamente.

Desconfio que algum alienígena está usando um artefato concentrador de tempestade magnética para causar tanta dificuldade. :D

Webinar: Como suportar um milhão de usuários simultâneos

Na semana passada fui convidado pela Eventials para fazer uma apresentação sobre WebPerformance. A apresentação foi a mesma que fiz na Campus Party 2013 e no Latinoware 2012. Provavelmente essa apresentação irá virar um artigo mas enquanto isso não acontece vocês podem assistir cliquando aqui.

Debian no FISL14

Neste FISL 14 temos muitas atividades Debian! :)

Atualmente são:

• Bastidores Debian - Entenda como a distribuição Funciona - Eriberto

• Oficina de criação de pacotes Debian - Loureiro

• Oficina da Maratona de Empacotamento - fike

• Integration of VistA Into Debian - Andreas Tille

• Debian Med Project - Andreas Tille

• GNUmed: Prontuário Eletrônico do Paciente do projeto Debian-Med Rogério Luz Coelho

• Plenária Debian

• Debian como seu desktop e colabore com o projeto - Albino

• Debian Linux kernel tuning cargas extremas I/O ambiente corporativo, sgbd, email André Felipe Machado

• Bastidores Debian - Entenda como a distribuição funciona Eriberto

Meu plano original era fazer a maratona de tradução no FISL mas como a oficina que foi aprovada foi de empacotamento, a maratona de tradução vai ser adiada um pouco. Mas é só um pouco. ;)

Então, pensando em como será a maratona de empacotamento (hackathon) Debian no FISL 14.

Pre-FISL

Objetivo do hackathon é ajudar o debian empacotando software que não estão empacotados no Debian, contribuir com pacotes existentes ou adotar um pacote órfão. Recomendação de leitura antes do FISL 14.

• Texto do Terceiro ”Participando do projeto Debian - como começar”

• Palestra do Eriberto ”Empacotamento de software no Debian GNU”

Se está você está começando agora, leia o que puder e procure um pacote ou um software para participar da maratona. Recomendo começar com um programa pequeno ou simples. Caso não tenha se identificado com algum time de empacotamento como o Terceiro comenta em seu texto, pode conversar comigo antes ou durante a maratona que posso ser o co-mantenedor ou fazer uma revisão antes de ser enviado por você para o Debian.

Existe muitos bugs nos pacotes que são fáceis de resolver: arquivo de licenças desatualizado, faltando página de manual, link quebrado do arquivo debian/watch, etc. Também no começo evite pacotes desenvolvidos em linguagens de programação que você não tem familiaridade, exceto se quiser aprendê-la.

Não precisa esperar a maratona, pode começar antes do evento. :)

Durante o FISL

Estarei a maior parte do FISL na área de grupo de usuários trabalhando nos pacotes, pode me procurar por lá. Também está nos planos raptar os desenvolvedores debian que estarão por lá para ajudar-nos com os possíveis pacotes NMU. Os NMUs a grosso modo acontecem quando sobe um pacote para o Debian em que o autor desta versão do pacote não é o “oficial”.

:)