Otimizando o Squid - Versão 2008

Otimizando seu Squid (Squid Tunning) - Versão 2008

A muito tempo, utilizo o squid para fazer cache em um provedor de internet a qual presto consultoria, e nesse carnaval de 2008, o servidor estava travando constantemente. Como o servidor, faz QOS, Controle de Banda e Firewall, pensei que um dos problemas pudesse ser o squid, além do que seu tempo de resposta estava alto. Em alguns instantes o uso de memória saía do habitual 1GB para 2GB, e nesse momento uma ou outra interface de rede parava de responder, e algumas vezes o syn era tao alto na porta 3128 e o syn cookie era ativado. Então minha primeira missão era minimizar e otimizar o uso de memória no servidor, sem muito penalizar o cache. Em todo momento a idéia era de aumentar o HIT Ratio, e ao mesmo tempo diminuir o consumo de banda, sem claro aumentar o tempo de resposta, que para o usuário final é a demora na abertura de páginas.

Procurando no site oficial do squid, procurei na parte de memória (Fonte: http://wiki.squid-cache.org/SquidFaq/SquidMemory ) O squid usa aproximadamente 10MB de memória RAM para cada Giga do Total encontrado no parâmetro cache_dir, mais a quantidade definida no cache_mem e um adicional de 10 a 20MB. Levando-se em consideração os serviços que roda no servidor, é aconselhavel o dobro da memória disponível para o squid no servidor. Portanto, se você possui um servidor com disco grande, mas uma quantidade limitada de memória RAM, NÃO se use todo o espaço em disco, e sim uma quantidade razoável levando as ponderações ditas acima. No meu caso, o servidor possui 2GB de RAM, e um disco rígido de 320GB, aloco 512 MB RAM no cache_mem, e 50GB para o cache_dir

Fazendo as contas do uso de memória:

cache_dir = 50GB -> 500MB de RAM usada

cache_mem = 512MB

Adicional de 20MB

O resultado: 500 + 512 + 20 = 1032MB RAM usada pelo squid.

Nesse caso, sobra aproximadamente 1GB para o Sistema, como possuo outros serviços no servidor, é um valor razoável.

Vejo nos em muitos artigos o parametro " memory_pools off " que de acordo com o FAQ do squid, não é uma boa pois induz a fragmentação de HEAP, nesse caso o mais indicado é o uso do memory_pools_limit

O parâmetro cache_mem por sí só, não limita a quantidade de memória usada pelo squid, e sim o tamanho do cache dos arquivos populares, entretanto, quanto maior o valor do cache_mem maior será o uso de memória do processo do squid, e se o squid está consumindo muita memória pense em diminuir a quantidade de memória usada no cache_mem. Como no meu caso a minha idéia é aumentar o HIT Ratio e ao mesmo tempo diminuir o consumo de banda, comecei a pesquisar também sobre o assunto. Encontrei no proprio arquivo do squid.conf os seguintes estudos, incluindo benchmarks (Fonte: http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html e http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html)

Feita a leitura, encontrei as políticas de troca de cache (cache_replacement_policy) com as 4 regras listadas.

lru : Squid's original list based LRU policy

Mantém em cache os arquivos abertos recentemente.

heap GDSF : Greedy-Dual Size Frequency

Otimiza o HIT Ratio de objetos mantendo os arquivos menores e populares no cache, para obter uma melhor chance de acontecer um HIT.

heap LFUDA: Least Frequently Used with Dynamic Aging

Procura manter no cache arquivos populares, independente do tamanho otimizando assim o Byte HIT em detrimento do HIT

heap LRU : LRU policy implemented using a heap

Mantém em cache os arquivos abertos recentemente utilizando-se a política heap

Nota: Para usar LFUDA deve-se aumentar o parâmetro "maximum_object_size" acima dos 4096KB padrão do squid para maximizar o Byte HIT, que é a prioridade da política.

Como eu tenho um cache com muitos usuários, e pensando na menos utilização de disco possível, tendo em vista que o seek time de um disco é muitas vezes mais lento que da memória RAM, preferi utilizar a política heap GDSF para a memória RAM disponível no cache_mem. Sendo assim meu arquivo de configuração ficou com o parâmetro "memory_replacement_policy" da seguinte forma

memory_replacement_policy heap GDSF

Prover internet com qualidade e preço competitivo é muito difícil para os pequenos, ou mesmo pra quem está dentro de uma empresa, minimizar o custo do link é importante, por isso, diminuir o consumo de banda é outra prerrogativa de um bom adminstrador. Por isso, tem-se que equilibrar a velocidade de acesso e o uso de banda, e para isso aumentamos o Byte HIT. Como a política LFUDA otimiza o Byte HIT, é ela que será usada no cache_replacement_policy. Dito isso o parâmetro ficará:

cache_replacement_policy heap LFUDA

O maximum_object_size, deve ser aumentado, e como vão ser cacheados arquivos grandes, tipo as atualizações do windows, o parâmetro foi definido como:

maximum_object_size 102400 KB ( 100MB )

A idéia das regras GDSF e LFUDA para as diferentes políticas é a seguinte, mantendo arquivos populares e pequenos no cache_mem (GDSF) eu aumento o HIT do servidor e diminuo o tempo de resposta do squid, pois evito que o disco rígido fique procurando arquivos pequenos. E com o LFUDA eu mantenho os arquivos populares e maiores no servidor e aumento o Byte HIT, adicionalmente, como é sabido, a transferência de arquivos maiores é mais rápida, indiretamente há uma otimização do uso do disco.

Abaixo, um benchmark feito com todas as políticas descritas acima.

Dica Importante: Mesmo que você não queira usar as políticas de popularidade GDSF e LFUDA, considere utilizar pelo menos no cache_replacement_policy o heap com LRU. Utilizando-se do heap a LRU tem uma melhora significantemente o tempo de resposta e transferência dos arquivos em cache se comparado a LRU tradicional.

Grafico do tempo de transferencia das políticas.

Como pode ser visto acima, a regra LRU presente na configuração padrão do squid possui um tempo de resposta muito inferior as políticas que usam HEAP, portanto a dica acima deve ser levada em consideração.

Ainda com objetivo de melhorar o acesso ao proxy e ao disco, uso o diskd que segundo o FAQ do squid, obtém aproximadamente 160 Req/s ao contrário dos outros dois tipos, (UFS e AUFS), que conforme o mesmo benchmark, possibilita 40 Req/s (Requisições por segundo)

cache_dir diskd /var/spool/squid 50000 64 256 Q1=64 Q2=72

Nota, os parametros Q1 e Q2 afetam diretamente a performance do cache, se Q1 > Q2 o diskd otimiza o diretório de cache para um menor tempo de resposta e, ao contrario, se Q1 < Q2 o diskd otimiza o diretório de cache para um aumento do HIT RATIO.

Para aumentar a quantidade de arquivos que o squid pode abrir, é interessante aumentar o número de file descriptors do squid. O kernel atual série 2.6+ já não precisam mais de patch para aumentar o número de file descriptors ( cat /proc/sys/fs/file-max ) e aumente para um número razoável. Uma forma elegante é usar o sysctl (exemplo: sysctl -w fs.file-max=100000) Já o squid, precisa de compilar com o parametro SQUID_MAXFD, mas o debian, vem com um patch onde vc pode editar o arquivo /etc/defaults/squid onde o valor máximo é 4096, depois basta reiniciar o squid.

Para minimizar o uso do squid, o parâmetro "half_closed_clients" deve ser setado em off, a alteração se deve porque muitas vezes o squid não diferencia um cliente que encerrou a conexão, e uma conexão travada, ou meio encerrada. ( Fonte: http://www.squid-cache.org/Versions/v2/2.6/cfgman/half_closed_clients.html tuning)

Artigo de Wagner Assis em 07/02/2008

Segue abaixo 2 artigos feitos posteriormentes relacionados ao Squid e suas otimizações.

Errata: Otimizando o Squid Versão 2008
http://www.linuxadm.com.br/2009/02/03/errata-otimizando-squid-versao-2008/

Squid Tuning - Mais dicas, aumentando a performance de disco
http://www.linuxadm.com.br/2008/06/14/squid-tuning-mais-dicas-aumentando-a-performance-de-disco/