28 abril 2010

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.

benchpolicyrr5

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.

benchresponsetimezb7

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)

Fonte: LinuxAdm (Wagner Assis) - http://www.linuxadm.com.br/2009/02/03/errata-otimizando-squid-versao-2008/

Squid Tuning – Mais dicas, aumentando a performance de disco.

Caros amigos leitores,

Após algumas pesquisas sobre SQUID e suas performances. Acabei descobrindo muitos materiais. Mais duas publicações me chamaram muita atenção. Squid Tuning – Mais dicas, aumentando a performance de disco e Otimizando o Squid - Versão 2008, publicados no site www.linuxadm.com.br.

Logo abaixo estarei republicando o texto na integra, para poder compartilhar este material com voces.

Procurando mais informações a respeito do Squid, me deparei na seguinte página. http://wiki.squid-cache.org/BestOsForSquid e descobri duas dicas a mais para melhorar o acesso a disco e consequentemente a resposta dos arquivos em cache.

Esse artigo deve ser considerado uma continuação do anterior “Otimizando o Squid – Versão 2008″, disponível em http://linuxadm.blogspot.com/2008/02/otimizando-o-squid-verso-2008.html

1ª Dica – noatime option

O Linux salva em cada arquivo a informação de data e hora de ultimo acesso além de ultima modificação, e como o Squid utiliza seu timestamp próprio, é inutil contar com o timestamp do filesystem. Para melhorar o acesso aos arquivos de cache setamos então o diretório de cache com o parâmetro “noatime”.

Como fazer? Simples.
Se o seu diretório de cache está numa partição em separado (o que a propósito é uma excelente idéia) basta adicionar o parâmetro noatime no seu fstab.

Exemplo:
/dev/sda3 /var/spool/squid reiserfs defaults,noatime 0 2

obs.. Recomendo adicionar o noatime somente nas partições do cache, não em partiçoes do sistema, tal como /

Se você já possui um particionamento, e não deseja reparticionar seu disco, pode fazer através do comando chattr (change attribute)

Exemplo:
#chattr -R +A /var/spool/squid
(Onde o -R é para recursividade, e o +A para especificar o noatime)

Para usar o chattr com ReiserFS é necessário ativar o suporte no Kernel.

[*] ReiserFS extended attributes
[*] ReiserFS POSIX Access Control Lists
[*] ReiserFS Security Labels

Para visualizar os atributos do arquivo utilize o lsattr.

Exemplo:
#lsattr
————- ./radius.sql (Arquivo sem nenhum atributo ativo)

2ª Dica – Espaço Livre (free space)
Sempre deixe acima de 20% de espaço livre no filesystem contendo seu cache dir, geralmente a performance do filesystem degrada dramaticamente se o espaço usado excede 80%.

3º Dica – Desativar o Store.log (Enviada por YellowBR)
Como dito anteriormente, quanto melhor otimizarmos o acesso a disco mais rapido será nosso proxy, uma forma de melhorar a performance de disco é reduzir a escrita desnecessária.
O store.log exibe quais arquivos foram removidos do cache, quais objetos estão salvos, e o tempo que estão no cache, entretanto, não existe uma utilidade real para esses dados, portanto é recomendável desativar essa flag.
Exemplo:
cache_store_log none

Fonte: http://www.visolve.com/squid/squid24s1/logfiles.php

Dica Extra (E extremamente útil) – notail option
Se você usa ReiserFs (o que é indicado para cache do squid) é interessante o uso da opção notail ao montar o sistema de arquivos. O “tail packing” é uma característica do ReiserFS para melhor uso de espaço, que permite 5% a menos de perda de espaço em disco se comparado ao ext2 ou ext3, a grosso modo ele faz um agrupamento de arquivos menores que um bloco do filesystem (4k), por isso a excelente performance do ReiserFS com arquivos menores.

Fonte: http://www.funtoo.org/en/articles/linux/ffg/2/

Portanto se você está disposto a sacrificar 5% do estaço em disco para um incremento de performance, ative a opção notail no seu fstab.

/dev/sda3 /var/spool/squid reiserfs defaults,noatime,notail 0 2

Se você não quiser reiniciar seu linux, basta apenas remontar a partição com o parâmetro notail.

#mount -o remount /var/spool/squid

As últimas duas dicas não referem-se apenas ao Squid, mas ao uso do sistema operacional em sí, procure manter o mesmo procedimento para sua partição primária.

Outras dica óbvia, e não menos importante, é procurar disco com velocidades maiores, por exemplo discos de 15k RPM.

Estarei adicionando essas dicas no arquivo original, mas manterei esse post em separado para que os antigos leitores vejam que houveram incremento de informações no tutorial.

Fonte: LinuxAdm (Danilo) – www.linuxadm.com.br