[FUG-BR] OT: lusca só da TCP_MISS, nenhum HIT

[Enio Marconcini # www.Enio.Pro.Br]

2010/9/17 William David Armstrong - FUGBr <fugbr em biosystems.ath.cx>

> Boa tarde
>
> Diminui  o tamanho da ram para ver se e força os objetos a irem pro disco
> as vezes a otimização do dos objetos esta tão boa que ele usa o que ja esta
> na ram o default é 8mb de ram tente  usar  32 mb apenas  aumente também o
> tamanho do arquivo máximo enviado.
> divida também o cache dir em 2 200gb seco é muita coisa para apenas um
> daemon de disco gerenciar.
>
> com esta o mountpoint desse cache .
>
> outra coisa
>
> Quanto memória eu necessito em meu Servidor para o Squid ?
> Em geral no Squid usa aproximadamente 10 MB de memória RAM por GB do total
> de todos os cache_dirs ( mais em servidores Alfa 64-bits ), além do seu
> ajuste do cache_mem ajuste para que sobre uns 10-20 MB adicionais.
> Recomenda-se ter ao menos duas vezes está quantidade de RAM física
> disponível em seu servidor do Squid.
>
> Para melhores detalhes no uso da memória e como configurar o Squid ,
> consulte a Documentação e o FAQ do Squid.
>
> Cálule uma memória RAM extra recomendada, além de o que é usada por Squid,
> que também será compartilhada pelo OS para utiliza-lá a fim de melhorar o
> desempenho do acesso I/O aumentando os cache buffers e por outras aplicações
> ou serviços que funcionam no Servidor. diminuindo o uso do SWAP e liberando
> mais I/O para os processos do cache_dir do Squid. Deve-se seguir está regra
> pois mesmo que você tenha apenas em servidor o Squid como o único serviço do
> tcp rodando, existe um nível de memória mínimo necessitado para rotinas
> gerênciamento de processos, registros, e o outras rotinas internos do OS.
>
> Se você tiver um servidor com pouca memória, e um disco grande, Você não
> poderá necessariamente usar todo o espaço de disco, porque quando a partição
> se encher, a memória disponível será insuficiente, forçando o Squid a
> esvaziar o buffer de memória e afetará assim o desempenho.
>
> Um cache_dir muito grande e uma quantidade de memória física total
> disponivél insuficiente + o Swap podem fazer com que o Squid pare de
> funcionar completamente. A solução para partições maiores deve ter mais RAM
> física; somente reservar mais RAM ao Squid através docache_mem não ajudará.
>
> Você também deve ler sem falta. Six Things First-Time Squid Administrators
> Should Know ( inglês ) e Eleven Metrics to Monitor for a Happy and Healthy
> Squid ( inglês )
>
>
> Em 16/09/2010, às 21:13, Enio Marconcini # www.Enio.Pro.Br escreveu:
>
> >> cache_mem                               512 MB
> >>
> >>
> >> maximum_object_size                     128 MB
> >> minimum_object_size                     1 KB
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>


amigão valeu pelas dicas, muito interessante mesmo,
consegui resolver, pelo menos agora está dando HIT´s, só não entendi a conf
que eu mudei e voltou a funcionar por percebe-se que não lógica.

eu tinha uma conf assim

dst que nao serao cacheados
acl dst_nocache dst "/usr/local/etc/squid/regras/dst_nocache.txt"
no_cache allow dst_nocache
always_direct allow dst_nocache

este arquivo dst_nocache.txt continha apenas um ip de um site que eu não
queria que fosse cacheado, deixei comentado todas essas 4 linhas acima, e
comecei a monitorar, está aparecendo diversos HITs agora, mas ainda estou em
testes pra saber se realmente foi isso mesmo.


agora outro problema é que, em alguns servidores eu utilizo o HAVP com o
Clamav, analisei o access.log do lusca, nenhum HIT, apenas MISS, desativei o
redirecionamento do lusca para o havp, e voltou a dar HITs. Neste setup, eu
tenho o lusca transparente, e este redirecionando pelo havp como um
proxy-parent assim:

acl porta_ftp port 20 21
always_direct allow porta_ftp

acl sites_fora_antivirus dstdomain
"/usr/local/etc/squid/regras/sites_fora_antivirus.txt"
always_direct allow sites_fora_antivirus

cache_peer 127.0.0.1 parent 8080 0 no-query no-digest no-netdb-exchange
default
cache_peer_access 127.0.0.1 allow all
acl ScanHTTP proto HTTP
never_direct allow ScanHTTP

o HAVP é apenas proxy que trabalha com antivirus, não faz nenhum filtro nem
faz cache, então percebi que deste modo, rodando transparente e
redirecionando para o havp, eu perco o cache, então preciso tentar o
inverso, que já havia feito uma vez mas não tinha analisado a eficiencia do
cache: colocar o havp pra escutar na porta 3128, e este redirecionar para o
lusca.

abraços


-- 
ENIO RODRIGO MARCONCINI
gtalk: eniorm em gmail.com
skype: eniorm
msn: /dev/null

.: FreeBSD -:- OpenBSD -:-Slackware Linux :.
Have trouble with Windows - reboot!
Have trouble with Unix - be root!