Tuning no Squid

junho 5, 2008

Tuning no Squid

Continuando meus posts sobre Squid, hoje vou mostrar como deixar seu Squid mais “parrudo”. Iremos apenas modificar alguns parâmetros no arquivo de configuração que podem surtir um efeito satisfatório na navegação dos usuários. Vamos lá!

Começando pela memória utilizada pelo squid.

A contagem é bem simples. O squid utiliza 10MB de memória RAM para cada 1GB setado no parâmetro do Cache_dir, adicionado ao valor estipulado no cache_mem e por fim adicionando um valor de gordura de 20MB.

Exemplo :

Tenho um cache_dir com 10GB e um cache_mem de 512. Assim terei utilização na memória de 100MB + 512 + 20 = 632MB de utilização. Isso com uma memória de 1GB aguenta perfeitamente, pois uma maquina com o SO otimizada não utiliza mais 50MB de RAM, no fim ainda teríamos sobra para possíveis picos de utilização de outras aplicações.

Obs: Não é aconselhável ter cache_dir maior que 10GB, se necessário for ter cache maior que isso, é indicado criar partições separadas, pois com partições maiores que essa quantidade existe uma latência no retorno de informações, por conta do grande espaço a ser consultado. (Isso é um mito!!!)

Agora vamos para políticas de troca do cache:

Com o squid compilado “bonitinho” temos as seguintes políticas de troca:

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

Então pude concluir que:

A melhor política para memória é o GDSF, pois manipula pequenos arquivos. Muito interessante para cenários com muitos usuários.

Para guardar arquivos no disco a melhor é LFUDA, pois tem como função aumentar o bit HIT e assim economizar banda, sem falar na manipulação de grandes arquivos, que todo mundo sabe que é bem mais rápido no disco.

Temos os seguintes parâmetros:

memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA

Obs : Aumente o parâmetro maximum_object_size para ganhar vantagem do LFUDA. (100MB para ambiente com atualizações grandes na internet).

Sistema de arquivos do cache:

No parâmetro cache_dir é o local utilizado para especificar o filesystem e informar os detalhes do mesmo.

O melhor sistema de arquivos em minha opinião é o diskd, que tem uma performance de 160 requisições por segundo.

O meu cache_dir ficaria da seguinte forma:

cache_dir diskd /var/spool/squid 10000 64 256 Q1=64 Q2=72
O primero parametro depois do local é o tamanho maximo do diretorio de cache.
O Segundo parametro é o numero maximo de pastas criadas no primeiro nível do cache_dir.

O terceiro parametro é o numero maximo de pastas criadas no segundo nível do cache_dir.
O Q1 e Q2 representam :

Q1 é o numero maximo de requisições para que o proxy pare de abrir novos arquivos.
Q2 é o numero maximo de requisições para que o proxy bloquei novas requisições.

Então:

Quando Q1 > Q2 (o padrão) tem um menor tempo de resposta, por conta do bloqueio antes que o máximo seja realmente excedido . Trocando a ordem (Q1 < Q2)  ganhamos performance, pois com o processamento rápido do cache para requisições não serão facilmente bloqueadas.
Numeros de arquivos que o squid pode abrir:

O kernel, junto ao squid, tem um limite de arquivos que pode ser aberto para manipular o cache e o repasse de paginas para os clientes.

Qual o limite do seu kernel?

# cat /proc/sys/fs/file-max

Deseja Aumentar?

# sysctl -w fs.file-max=100000

No squid isso é feito no ato da compilação com o parâmetro –with-maxfd=<numero>

PS: Cuidado com o numero de arquivos, para que não tenhamos um sobrecarga no seu sistema. Eu utilizo 16384, que veio no padrão do rpm no CentOS 5. Achei um bom numero.

Fechando conexões “meio encerradas”:

O squid mantem algumas conexões que não foram encerradas pelo cliente, mas não estão em uso. Sendo assim o parametro half_closed_clients deve ser setado como off.

Obs : Todos essas dicas foram testadas na distribuição CentOS 5.1 em ambiente virtualizado com 2 GB de RAM dedicados.

Fonte

Anúncios

Meu primeiro Patch

maio 28, 2008

Meu primeiro Patch

Olha só! Depois de ter lido o post do meu amigo Cárlisson Galdino, resolvi fazer um patch para solucionar um problema especifico. Vou explicar melhor abaixo:

A pouco tempo atrás, escrevi um artigo sobre a instalação do DBDesigner no Fedora. No meio dos procedimentos tinha a informação de como mudar um parâmetro de conexão do banco para que a conexão funcionasse corretamente.

Depois de algum tempo de escrito, me peguei pensando que poderia haver uma maneira mais “jeitosa” para resolver aquele armengue, que era necessária em TODA conexão criada, de mudar os parâmetros.

Sendo assim começou minha busca pelos arquivos do programa. Assim descobri que o DBDesigner guarda na pasta Data os arquivos de padrões para os parâmetros, porém algo que me “torrou a paciência” foi mudar esse arquivo e não atualizar nada no Software. Depois de muito tentar, descobri que o DBDesigner cria um diretorio oculto (.DBDesigner4) no Home de cada usuario, na sua primeira utilização, e assim eu tinha que mudar o arquivo lá também, ou no caso simplesmente removê-lo. Tanto faz, somente a titulo de informação, pois o que está em foco era o fato de com posse do arquivo, a criação do patch se faria muito eficaz, já que os usuários apenas executariam  um comando e o problema seria resolvido.

Depois de ler o artigo do Cárlisson Galdino, que é BEM fácil, consegui criar meu PRIMEIRO patch. Feitos os devidos testes com sucesso, hospedei ele em um site de compartilhamento de arquivos.

Infelizmente não posso contribuir com o projeto DBDesigner, pois a ferramenta que o programa usa para acessar o banco é proprietária e a simples referência de sua biblioteca no arquivo do meu patch poderia causar problemas ao projeto. Sendo assim disponibilizo de outras formar para o usuário final. Não vou entrar no merito da legalidade disso. Eu não vejo grandes problemas, mas…

Obrigado Cárlisson,