Moksha...

Das experiências que eu tive com o squid em tremos de alto processamento.

1- ele é monoprocessado. Isso quer dizer que você pode colocar a máquina
com quantos core forem que ele vai utilizar apenas 1. Fato. A versão 3.2,
que está em desenvolvimento já utiliza SMP.

2- Em função do "problema" acima, evite utilizar ACLs que demandam mais
processamento, especialmente as que usam expressões regulares
(dstdom_regex, urlpath_regex, url_regex, etc) e autenticação em serviços de
diretório (AD, ldap...)

3- Caso não consiga fugir da situação acima, experimente "dividir" a sua
arquitetura, ou seja, colocar em várias instâncias. No meu caso, não
precisei, só de alterar as ACLs resolveu, mas achei um post interessante,
simples e bem explicado:


http://wiki.squid-cache.org/ConfigExamples/MultiCpuSystem


[ ]'s




2012/8/10 Adiel de Lima Ribeiro <adiel.netad...@gmail.com>

> **
> Boa tarde, tem como enviar-nos seu squid.conf ?
>
>
>
> On Fri, 2012-08-10 at 16:30 -0300, Moksha Tux wrote:
>
> Boa tarde pessoal!
>
> Estou há muitos meses as voltas com o proxy daqui do meu trabalho, já faz
> um bom tempo que a CPU do servidor trabalha quase o expediente inteiro de
> trabalho oscilando entre 70 a 100%, a rede daqui do trabalho é segimentada
> por VLANs e temos por volta de 2500 usuários e mais de 2200 hosts e a
> configurção do hardware é robusta  (Servidor IBM X3650 CPU Intel Xeon de 8
> núcleos e 4 GB de RAM e armazenamento de 1.3 TB sendo 6 discos SAS 15 krpm
> em RAID 5), já fiz muitos testes a saber... regra de firewall barrando uma
> VLAN por vez para analisar o desempenho e fluxo de conexão, levantei o
> proxy em outro hardware, fiz partições separadas do cache, log e em
> reiserfs e nada disso está adiantando, alguém poderia me ajudar? Será que
> seria a versão deste squid do Debian squeeze apresentando bug? A minha rede
> é Gigabit o que também não justificaria tal desempenho. O que mais devo
> fazer? Obrigado a todos pela atenção! Abraços,
>
> Moksha
>
>
>   --
> Adiel de Lima Ribeirofacebook.com/sembr.dyndns.info
>
>


-- 
Bruno Ayub.

Responder a