quinta-feira, 7 de fevereiro de 2008

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/

8 comentários:

Rafael Gomes disse...

sensacional o post! irei criar um post em meu blog e irei referencia-lo! Muito bom mesmo! Tirou muitas duvidas!

Até mais!

standart disse...

Olá Wagner!! Fiquei tão impressionado com seu conhecimento sobre o assunto de decidir montar um servidor para testas estas soluções, mas ate o momento estou sendo infeliz, todas as paginas que acesso voltam com esse log:
10.0.0.200 TCP_MISS/200

algumas poucas assim:
10.0.0.200 TCP_REFRESH_HIT/304

Voce saberia me informar se isto esta certo?

Valeu

Wagner Assis disse...

Olá Standart, respondi seu comentário como um novo post.
Abraços.

Anônimo disse...

Seus trabalhos são excelentes, porém os trabalhos sobre o squid são excepcionais! Meus parabéns Wagner!
Ass: Leo

OBS: Se vc tiver alguns truques no dansguardian ficariamos agradecidos.

superxandao disse...

Amigo, bom final de semana
Algum de vcs teria como postar como ficou o squid.conf ?
Um que esteja funcional ?

Jose Carlos Oliveira disse...

Caros Wagner e Danilo,

Fico contente quando encontramos bons materiais em uma busca no google. O que é dificil, hoje em dia. Acha-se muita coisa repetitiva e poucos materiais que tem o enfoque correto ou melhor ao ponto certo. Não só fiquei feliz em descobrir este excelentissimo, como os publiquei em meu blog com todos os creditos e referencia a Voces.

Muito obrigado.

Jose Carlos Oliveira
Administrador de Redes SR
http://sixsideweb.blogspot.com

Jose Carlos Oliveira disse...

Caros Wagner e Danilo,

Fico contente quando encontramos bons materiais em uma busca no google. O que é dificil, hoje em dia. Acha-se muita coisa repetitiva e poucos materiais que tem o enfoque correto ou melhor ao ponto certo. Não só fiquei feliz em descobrir este excelentissimo, como os publiquei em meu blog com todos os creditos e referencia a Voces.

Muito obrigado.

Jose Carlos Oliveira
Administrador de Redes SR
http://sixsideweb.blogspot.com

Wellington Torrejais da Silva disse...

Muito bom!