ccasado.com/blog

A conferência sobre desenvolvimento opensource da Apache Software Foundation ocorreu entre os dias 03 à 07 de Novembro em New Orleans (Louisiana) e eu estava lá pela Globo.com para conferir. A variedade de atividades era grande, e optei acompanhar o treinamento denominado Apache Nuts to Bolts voltado para administradores de sistemas. O primeiro dia de treinamento teve como “speakers” William A. Rower Jr e Jim Jagielski (chairman ASF), ambos com inúmeras contribuições para projetos da Apache, e o conteúdo foi organizado como uma introdução ao Apache HTTPD 2.2 para administradores de nível básico a intermediário. William começou falando sobre a estrutura de documentação do httpd server, o Wiki com informações sobre módulos em desenvolvimento, exemplos de configurações e howto´s , mostrou os principais repositórios de download dos binários e sources, verificação de autenticidade utilizando pgp, instalação em modo gráfico no Windows e em Unix command line no Linux. Na parte de configurações de MPM (Multi-Processing Modules) um estímulo, que também ouvi em outras sessions, para a utilização do modo prefork, mais maduro na versão 2.2, para o sistema operacional Linux. Em comparação ao modo worker é menos escalável pois não lida com threads, porém é muito mais robusto no Linux devido ao isolamento de cada request em seu próprio contexto. É a recomendação para os casos de core dump e thread-safe issues com o worker no Linux. Mostrou também um guia com layouts default de instalação em diferentes sistemas operacionais e distribuições, a utilização do mod_logio para o administrador acessar as informações de bytes recebidos e enviados por requests, utilizando a linha de configuração de log:

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\” %I %O” iologging
CustomLog “logs/io.log” iologging

Também foi recomendado a nível de performance a utilização de alternativas ao uso de Rewrite, com diretivas de Redirect, RedirectMatch, Alias e PathInfo. Em sites de alto tráfego podem ocorrer uso intensivo de memória ram com uso de Rewrite e da engine de regexp do sistema operacional.

Para quem usa Rewrite, uma forma de tornar o log mais amigável, direcionando o log do módulo para um script em perl:

RewriteLog |/usr/local/bin/rewrite_log_pipe
RewriteLogLevel 9

#!/usr/bin/perl
# rewrite_log_pipe
$|++;
open (F, “>>/tmp/rewrite”);
select F;
while (<>) {
s/^.*(\(\d\).*)/$1/;
print;
}

O segundo dia de treinamento foi ministrado por Rich Bowen, co-autor dos livros Apache Administrator´s Handbook e Apache Cookbook, e pelo Jim Jagielski. Em um nível mais avançado foi mostrado como montar uma topologia de reverse proxy (server-side proxy) utilizando diretivas de ProxyPass, ProxyPassReverse e se necessário RewriteRule. Neste exemplo os requests para o recurso /secure são repassados via proxy para servidores seguros no backend com permissão para execução de scripts (cgi-bin) e com acesso negado para a internet:

internet <-> webserver (reverse proxy) <-> firewall <-> server application

Estão presentes no mod_proxy o suporte aos protocolos http, https, connect, ftp, ajp, fastcgi (eca). LoadBalancing com suporte a afinidade de sessão (sticky session) e Clustering com failover e hot standby.

Finalizado os dois dias de treinamento, fui participar da session Scalling Apache 2.x in all dimensions com o Colm MacCarthaigh. Ele mostrou como elaborar benchmarkings e tuning para o httpd server.
Iniciou com uma informação que passa transparente para a maioria dos administradores, a quantidade de system calls no sistema operacional para uma transação http completa:

1. listen( ) + fork( ) / thread_create( )
2. poll( ) / select( ) / epoll( ) / rqueue( ) / port_get( )
3. accept( )
4. stat( ) / readdir( ) / stat( )
5. read( ) / write( )
6. close( )

Os pontos que devem ser considerados para um ambiente otimizado para performance: network latency, storage performance, kernel performance e webserver performance.

A metodologia de configurar, testar, configurar, testar, configurar, testar e então realizar o benchmark (isso quantas vezes for necessário).

Para o benchmark a importancia extrema de simular o mundo real (produção), com tráfego perto do esperado. A utilização de ferramentas como ab, httperf, autobench, siege, flood e specweb. E talvez o mais importante nesta fase: ser sistemático.

Ferramentas para benchmark de filesystems e storages como iozone, bonnie++, dbench e tiobench.

Para a performance de network a recomendação de desabilitar a feature de TCP checksum-offloading, a quantidade de memória disponível para a pilha TCP e os tempos de KeepAlive.

Para o tunning do Apache, habilitar KeepAlive, experimentar valores de buffer TCP com as diretivas SendBufferSize e ReceiveBufferSize, otimizações de listening sockets com a diretiva AcceptFilter e “de novo” evitar a todo custo a utilização de regular expressions com frases de efeito do tipo “Se você pode fazer algo sem Rewrite, faça”.

A recomendação de testes com prefork em Linux com configurações do tipo (valores somente de exemplo):

ServerLimit 200
StartServers 200
MinSpareServers 200
MaxSpareServers 200
MaxRequestsPerChild 25

A utilização da diretiva EnableSendFile (com cuidado) para utilizar o suporte a sendfile do kernel para servir arquivos estáticos ao cliente, escrevendo o conteúdo direto no socket, sem que o httpd faça um read no arquivo e carregue para a memória.

Assim como o cache em disco (mod_disk_cache) pode ajudar em algumas situações.

A session seguinte teve o nome Building scalable web applications and clusters com o Brian Moon que mostrou estratégias vencedoras em escalabilidade utilizando LAMP.

Começou com a definição de “escalar” como ações de performance e aprimoração de features com contínuo ganho de tráfego.

Como os pontos mais comuns de gargalos, o banco de dados como o principal gargalo em web sites, web services externos a sua estrutura e maus programadores para qualquer tipo de linguagem.

Regras de sharding e partitioning como dividir a informação (dado) em múltiplos sets de banco de dados (servidores ou instâncias), usar o registro replicado para localizar um objeto e a possibilidade de escalar a leitura em db enquanto é utilizado replicação.

Processamento Offline para qualquer coisa com tempo de processamento >1 segundo e que não permita que o carregamento de uma página ou um request seja concluído. Utilizar outros servidores não-web ou application server para processamento dos dados. Processamento de logging ou tracking de usuário somente offline.

Cloud como uma boa solução para processamento imediato, com inicialização de instâncias somente quando necessário.

Conteúdo que não é alterado com frequência em cache, utilizando pushed cache quando possível, cacheando os objetos mais acessados. Assumir a impossibilidade de seguir em frente caso nenhum objeto possa ser cacheado no sistema. Como estratégias o Reactive Cache, que é o mais comum, onde os dados são cacheados enquanto são requisitados, Pushed Cache onde os dados são armazenados enquanto são transformados e independente da requisição do usuário.

Cachear dados é ter paciencia, onde o administrador ou desenvolvedor deve se perguntar diversas vezes se o conteúdo realmente precisa ser em realtime e paciencia para encontrar a melhor métrica de hit/miss ratio.

Se possível executar testes em ambiente de produção, isolando o hardware neste ambiente para os testes e planejando os testes para a noite ou em momentos de baixo tráfego. Você não terá resultados mais confiáveis que não sejam com o hardware e com os dados de produção. Fale para todos que você será responsável em cuidar disso. Nos testes, gerar gráfico de tudo, assim como printscreen de telas.

Para gerar os gráficos: cacti (interface decente e fácil configuração), ganglia (similar ao cacti e utilizado pelo Flickr), Hyperic. Como métricas o consumo de memória, disk I/O, bandwidth, tempo de processamento e métricas customizadas para dados de negócio.

Encerrado o terceiro dia (05/11) com saldo bastante positivo.

Iniciei o quarto dia com a session Apache Project on Dtrace Developer Experienced com o Theo Schlossnagle, sobre como analisar problemas de performance utilizando a ferramenta Dtrace.

O Dtrace não é uma simples métrica de observação como top, prstat, mpstat, iostat ou vmstat. É uma ferramenta poderosa para análise de um sistema em todas as suas camadas. Theo falou de grandes experiencias obtendo informações de sistemas em produção em poucos minutos.

Como pré-requisito um sistema operacional que suporta Dtrace, como Solaris, OpenSolaris, Mac OS X, FreeBSD e Linux (quase lá).

Para usar o Dtrace com responsabilidade você deve conhecer todos os systems calls, o que eles são e quando são invocados. A estrutura e implementação do kernel. A implementação do sistema de memória virtual (VMS). A implementação do sistema virtual de arquivos (VFS). Sistemas de I/O. Linguagem C, stacks … portanto quase um monge

O Dtrace fornece: syscall, sysinfo, vminfo, sched, io, mib, profile, fbt, fasttrap, fpuinfo, lockstat, proc, pid, plockstat, ip, iscsi, nfsv4, nfsv3, sdt.

Esta é a página do Wiki Dtrace.

Na session A Tour of Apache Hadoop, Tom White, autor do livro Hadoop The Definitive Guide, mostra como lidar com sistemas utilizando processamento de dados distribuido.

Os tipos de problemas que o Hadoop ajuda a resolver, como processamento de “big data” (terabytes e petabytes), análise de dados em batch (não online) e dados inestruturados ou semi-estruturados. Os problemas que o Hadoop não irá ajudar como processamento de lotes de grandes quantidades de arquivos pequenos e online queries.

Dicas de onde armazenar os arquivos para o processamento utilizando filesystem distribuido (HDFS).

Em um exemplo prático o processamento de logs de webserver para coletar dados estatísticos. A leitura dos logs efetuada a partir de um HDFS, utilizando o formato de logs com campos separados por tabs, escrita local dos arquivos no disco do webserver movendo periodicamente para o HDFS utilizando o command line “hadoop -moveFromLocal”. A execucao de job para na hora de transferir combinar arquivos pequenos e grandes para performance do HDFS e MapReduce. SequenceFile para compressao de grandes arquivos.

Mostrou o PIG como uma linguagem desenvolvida pelo Yahoo! para analise de dados em grandes datasets. E o Hive como um “data warehouse system” com uma linguagem SQL-like.

A combinacao do MapReduce, PIG e Hive para performance e produtividade com Hadoop.

Outras contribuicoes como Chukwa que é um módulo para coletar e analisar dados a partir de HDFS. FailMon para monitoracao e coleta de informacoes de hardware em clusters Hadoop.

A session escolhida por mim para encerrar o evento foi Java Monitoring and Trouble Shooting Tools In Action com Bill Au.

Ele iniciou falando da instrumentação de monitoracao do Java 1.6 e do pacote java.lang.management para utilizar MBeans de monitoracao.

As formas de realizar um Thread Dump para analise de problemas utilizando kill -3 (ou kill -SIGQUIT), ThreadMXBean, jstack e jconsole. Um Heap Dump para analisar os casos de OutOfMemoryError utilizando o java option -XX:+HeadDumpOnOutOfMemoryError, jmap, jconsole ou hprof.

A estratégia para aplicacoes lentas com longas pausas de GC ou com overhead por GC em intervalos muito curtos, realizando tunning (heap size, serial/parallel/concurrent collector) e mensurando a cada alteracao de configuracao utilizando as ferramentas disponíveis. Desconfiar de threads em estado “runnable” (stuck threads) com mesmo stack ID em threads dumps diferentes, normalmente causados por chamada a recursos de rede com tempo alto de resposta.

As causas mais comuns para OutOfMemoryError:

heap size mal configurado;
arrays com tamanho maior que o heap size;
objetos com “finalizers” pendentes;
área de permanent generation muito pequena (ajustar usando -XX:MaxPermSize <size>);
pouca memória disponível no sistema operacional (verificar alocacao para outros processos);
processos excedendo o seu tamanho máximo, neste caso reduzir o tamanho da heap ou do stack de memória;
leak no código da VM, neste caso verificar o log de fatal error (hs_err_<pid>.log) e/ou realizar upgrade de versão do java.

Links relacionados:
Search modules
#apache irc channel
Apache Mail List
Fotos da viagem