Tunning Squid - Para alto tráfego

Publicado por Rafael Mendes em 15/06/2012

[ Hits: 25.215 ]

Blog: http://www.linkedin.com/pub/rafael-mendes/23/799/6a4

 


Tunning Squid - Para alto tráfego



Nesta dica pretendo ajudar todos os usuários de GNU/Linux que fazem uso do Squid como servidor proxy.

Não serão abordadas configurações de regras de Squid, apenas iremos tratar algumas configurações necessárias para dar maior agilidade ao Squid, para aquelas pessoas que, assim como eu, tiveram problemas ao ter muitos usuários conectados ao proxy e a Internet tornar-se lenta.

Cenário

No cenário este "tunning" foi um servidor com 4GB de RAM, sendo 3 GB dedicados para o Squid. Dois discos SCSI de 10k com um processador Xeon 2.4 rodando Debian 6.

O mesmo está atendendo em horário de pico, em média de 1000 usuários simultaneamente, efetuando autenticações via winbind em um domínio NT (Active Directory) no Windows Server Enterprise 2008.

Modificando algumas configurações do kernel

Primeiramente vamos alterar alguns valores do kernel padrão, reduzindo o tempo de limpeza da tabela ARP e aumentando o seu tamanho, bem como aumentando o número de conexões simultâneas que o servidor irá atender e reduzir o tempo de espera entre as conexões.

Para isso, vamos alterar o arquivo sysclt.conf:

# vim /etc/sysctl.conf

E no final do arquivo, adicionar as seguintes linhas:

####### TUNNING PARA SQUID ########
# Reduzir o tempo de limpeza da tabela ARP
# Expandir o seu tamanho
net.ipv4.neigh.default.gc_interval = 15
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 16384

# Aumento do numero de conexoes simultaneas
# Reducao do tempo de espera entre as conexoes
net.core.somaxconn = 20480
net.core.netdev_max_backlog = 2048
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_max_syn_backlog = 2048

Após adicionar as linhas e salvar o arquivo, é necessário executar o comando "sysclt -p" para que as alterações sejam importadas pelo kernel.

Modificando os limits de segurança

Uma outra boa prática adotada foi modificar os valores de limits do kernel. Para verificar os limits do seu kernel, basta digitar o comando:

# ulimit -a.

No meu caso, apenas alterei o valor de 'open files', que no padrão era 1024 e passei para 16384.

Para fazer esta alteração, basta digitar o seguinte comando na console:

# ulimit -n 16384

Porém, ao reiniciar o servidor, os valores de 'limits' irão retornar para o padrão. Para que isso não aconteça, edite o arquivo limits.conf:

# vim /etc/security/limits.conf

No final do arquivo, inclua as seguintes linhas:

#### TUNNING DE LIMITS DE KERNEL #####
root soft nofile 16384
root hard nofile 32768
* soft nofile 16384
* hard nofile 32768

Considerações finais

Modificando configuração padrão do Squid.

Agora vamos alterar o valor padrão de arquivos de descritores abertos pelo Squid. Para isso edite o arquivo /etc/default/squid.

Neste arquivo tem um valor padrão de 1024, altere para 4096.

Pronto, o seu kernel para uso do Squid está 'tunado'... Uma alteração a gosto, de quem quiser testar, também foi modificar os parâmetros de leitura de cache no "squid.conf".

Percebi uma melhora significativa na velocidade de acesso ao cache ao usar o método diskd no lugar de aufs.

Em algumas pesquisas na Internet, encontrei registros em que o diskd consegue fazer até 160 requisições por segundo ao cache no disco, sendo que o aufs, gira em torno de 40 requisições por segundo.

Entendido isso, foi alterado o cache para os seguintes parâmetros:

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

Se pesquisarem sobre este parâmetro, deverão encontrar muita coisa, então não irei abordar o por quê dos por quês...

Feito estas configurações, recomendo reiniciar o servidor e levantar o Squid para ver as melhoras de performance.

No meu caso, a navegação ficou visivelmente mais rápida.

Outras dicas deste autor

Conexão SSH entre servidores Linux sem senha

Instalação do Dell OpenManage no CentOS 6.X

Compartilhamento NFS em Debian

Instalando repositório RPMforge no CentOS 6.2

Problema: Dell OpenManage não faz login (refresh na tela) no CentOS 6.4 [Resolvido]

Leitura recomendada

Instalação do MPlayer-1.0rc2 a partir do fonte no Slackware 12.1

Construindo uma URA (Unidade de Resposta Audível) no Asterisk 1.4.X

Habilitar RPM Fusion no Fedora/RHEL/CentOS (Atualizado)

Mudando a aparência do Grub no Ubuntu

Entendendo o FHS

  

Comentários
[1] Comentário enviado por cromado em 16/04/2013 - 19:14h

Interessante. vou fazer alguns testes.

Tks

[2] Comentário enviado por becktranck em 01/11/2016 - 10:03h

Bom dia!
Fiz conforme recomendando no tópico , mas estou me deparando com um erro de conexões winbind.

"winbindd: Exceeding 1000 client connections, no idle connection found"

Alguém já pegou esse erro ?
Tenho cerca de 700 usuários utilizando squid autenticando no AD , num hardware desktops I5 com 8GB de RAM e gostaria que suportasse até 1000 usuários conectados.

Agradeço a ajuda de todos.

Abs.

[3] Comentário enviado por rafael.mendes em 01/11/2016 - 16:33h

Olá @becktranck
Creio que o seu problema esteja no arquivo de configuração do smb.conf.

Dentro dele teves ter uma sessão onde esta definido a quantidade de sessões no cache do samba. Caso não a tenha defina conforme abaixo no seu smb.conf

idmap uid = 10000-30000
idmap gid = 10000-30000
winbind gid = 10000-30000
winbind enum users = yes
winbind enum groups = yes

No caso da config acima você estará liberando o samba para ler até 20.000 usuários do seu domínio. (pois estarão enumerados de 10.000 até 30.000)

Espero ter ajudado.

--
Att;
Rafael Mendes

[4] Comentário enviado por becktranck em 09/11/2016 - 10:01h

Rafael , bom dia!

Tudo bem amigão?

Deixei meu smb.conf conforme abaixo :

#####################################
[global]
realm = XXX.XXXX.COM
workgroup = JAGUARE
security = ads
# If the system doesn't find the domain controller automatically, you may need the following line
# password server = 10.0.0.1
# note that workgroup is the 'short' domain name
# winbind separator = +
idmap uid = 10000-30000
idmap gid = 10000-30000
winbind gid = 10000-30000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/%D/%U
template shell = /bin/bash
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
restrict anonymous = 2


Tenho notado que o consumo de memória vem crescendo gradativamente durante o dia e quando ocupa 90% do total a máquina trava, já fiz várias configurações de tunning , mas sem êxito ainda.

Vou analisar como vai se comportar o squid no meu ambiente e reporto posteriormente os resultados.

Abs e muito obrigado pela colaboração.

[5] Comentário enviado por rafael.mendes em 09/11/2016 - 14:02h

Olá Cleber....

Como esta sua linha de cache_dir? Se ela estiver pouco distribuída e com muito arquivo ira consumir muita memória mesmo...

Tenho um ambiente hoje rodando em torno de 500 acessos simultâneos e rodo o squid em uma maquina virtual com 8GB de RAM também....

Aqui a linha cache_dir esta funcionando bem com a seguinte configuração:

cache_dir aufs /var/spool/squid3 2560 32 256

Quando adicionar essa linha você ira precisar recriar o cache do squid... para isso de um stop no squid, e depois execute o comando "squid -z" e inicie o squid novamente. Valide se o caminho do cache do seu squid também esta em /var/spool/squid3... caso contrário adapte para seu ambiente.

--
Att;
Rafael Mendes
[email protected]
Analista de TI.
Joinville - Santa Catarina
RMIT Soluções | Soluções em Tecnologia da Informação.
Chamados: helpdesk.rmitsolucoes.com.br
Serviços: www.rmitsolucoes.com.br



Contribuir com comentário