[GTER] RES: Navegação através de proxy transparente ficando lenta até parar...

Sun Jan 3 06:12:18 -02 2010

Opa..

Vou deixar alguns comentários mas baseados em minha experiencia com BSD, que
é o que trabalho mais, mas creio que dá para adaptar ao seu cenário,
obviamente mudando a sintaxe e nomenclatura.

Como você verificou o I/O? Rodou um vmstat no momento do problema?
Tente ativar no fstab as opções "notail" e "noatime" na partição do cache,
até nos servidores que estão OK, para deixar a gravação de dados do cache
mais rápido.

Em linux o processo aufs é um sistema eficiente de pool de dados para o
squid ? No BSD o diskd tem um ganho fenomenal emcima do padrão ufs ou do
aufs.

Tive a algum tempo atrás um problema de core randômico e temporariamente
voltei para ufs para debuggar, mas após alguns minutos, e a navegação ficou
extremamente lenta como você relata, já que o processo do squid ficava só em
kqread(que no BSD indica que está esperando por entrada de dados externa),
ou seja, esperando o ufs ler o disco(que estava sem I/O) e entregar pro
squid.
No final o problema de core era um update mal feito da base do sistema, mas
ficou a dica do state kqread x UFS.

Quando a navegação fica lenta, o top mostra algum state anormal para o squid
ou para o subsistema do ufs? Talvez seja algo por aí.

Sobre o DNS, tente ativar um resolver local ouvindo em 127.0.0.1 para
eliminar problemas com o resolver do probedor.
Quando você fala que ativou suporte a High Memory(64 Gb), é algo relativo a
PAE? Ou o Linux é 64bits?  Pois no BSD 32bits, ao ativar o suporte a
PAE(para usar mais de 4GB ) só dá transtorno... hehee.

Por fim, tem algum motivo para não usar a série 3.0 do squid? Muita coisa
nele foi otimizada, incluindo aí o proxy transparente e o tproxy.

Este guia aqui[1] é velho(da época que o squid 3 era beta), mas parece ter
algumas dicas pra usar no ./configure, cita algumas que o pessoal aqui
sugeriu, dá uma olhada também!

[1]: http://blog.last.fm/2007/08/30/squid-optimization-guide
Abraços!

2010/1/3 Igor Luiz Oliveira de Souza <igorluiz at solic.com.br>

> A proporção que eu conhecia era de 10 Mb de RAM para cada 1 Gb de cache.
> http://www.linux-faqs.com/squid.php
> -----
> RAM
>
>    It's pretty easy to calculate the amount of RAM needed for any
> given web cache.  A safe number is 10MB RAM for every 1 GB of cache
> space on disk.  I usually allot a little more than this when using a
> threaded Squid.  Of course, you also need to figure out what your
> system uses for other things and subtract that from the total of
> available RAM. For my prototype unit I've chosen 256 MB.
> ------
>
> De qualquer forma vou chutar aquele valor pra cima, ver se faz
> diferença na hora do problema.
> --
>  Igor Luiz Oliveira de Souza
> Solic Tecnologia e Sistemas
> (77) 8829-7678
> igorluiz at solic.com.br
>
>
> 2010/1/2 Paulo Henrique <paulo.rddck at bsd.com.br>:
> > po não tenho não !!! lembro de ter lindo na FUG-BR, e depois de
> > simular um ambiente pude ver que 1Gbs de cache efetivo consumia 32Mbs
> > de ram com descritores..
> >
> > 2010/1/3 Igor Luiz Oliveira de Souza <igorluiz at solic.com.br>:
> >> Xiii... blz... vou botar aqui como ponto a testar... devo fazer logo
> >> esse primeiro, pois é prático...
> >> Tem algum link ou referência sobre essa relação? Onde posso achar
> >> esses cálculos?
> >>
> >> Valeu Paulo!
> >> --
> >> Igor Luiz Oliveira de Souza
> >> Solic Tecnologia e Sistemas
> >> (77) 8829-7678
> >> igorluiz at solic.com.br
> >>
> >> 2010/1/2 Paulo Henrique <paulo.rddck at bsd.com.br>:
> >>> cache_mem 512 MB < aumenta
> >>> o calculo que sei é 32Mb por Giga
> >>>
> >>> para 50Gbs de cache atual o valor mais proximo seria 1600 MB
> >>>
> >>> 2010/1/3 Igor Luiz Oliveira de Souza <igorluiz at solic.com.br>:
> >>>> :-(
> >>>> Sem chance do problema estar por ali então?
> >>>>
> >>>> --
> >>>> Igor Luiz Oliveira de Souza
> >>>> Solic Tecnologia e Sistemas
> >>>> (77) 8829-7678
> >>>> igorluiz at solic.com.br
> >>>>
> >>>>
> >>>> 2010/1/2 Alexandre J. Correa - Onda Internet <alexandre at onda.psi.br>:
> >>>>> Total in use = 100% é normal
> >>>>>
> >>>>> Total in use:          -1011287 KB 105%
> >>>>>
> >>>>> este server tem 16gb de ram.. por isso da valores negativos...
> (preciso ate
> >>>>> corrigir isto no lusca)
> >>>>>
> >>>>>
> >>>>> On 02/01/2010 22:26, Paulo Henrique wrote:
> >>>>>>
> >>>>>> Memory usage for squid via mallinfo():
> >>>>>>        Total space in arena:  851000 KB
> >>>>>>        Ordinary blocks:       850398 KB  31794 blks
> >>>>>>        Small blocks:               0 KB      0 blks
> >>>>>>        Holding blocks:         27348 KB      5 blks
> >>>>>>        Free Small blocks:          0 KB
> >>>>>>        Free Ordinary blocks:     601 KB
> >>>>>>        Total in use:          877746 KB 100%<<<  Estranho ?!
> >>>>>>        Total free:               601 KB 0%
> >>>>>>        Total size:            878348 KB
> >>>>>>
> >>>>>> 2010/1/3 Jean Franco<stuntshell at gmail.com>:
> >>>>>>
> >>>>>>>
> >>>>>>> Igor,
> >>>>>>> E um du -h pra mostrar o uso do disco, especialmente da partição do
> >>>>>>> squid?
> >>>>>>> E se vc limpar o cache e reiniciar o squid, volta ao normal?
> >>>>>>>
> >>>>>>> Abs,
> >>>>>>>
> >>>>>>> 2010/1/2 Igor Luiz Oliveira de Souza<igorluiz at solic.com.br>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Oi Anderson,
> >>>>>>>>
> >>>>>>>> Vou fazer o teste de reiniciar o daemon do DNS num momento de
> >>>>>>>> ocorrência do problema pra ver...
> >>>>>>>> Quanto ao access.log, posso desativar sem grande problema... só
> uso
> >>>>>>>> mesmo pra debug... nada de SARG ou coisa do tipo... vou testar
> isso...
> >>>>>>>>
> >>>>>>>> Quanto ao status da máquina no momento do monitoramento, você pode
> ver
> >>>>>>>> no meu e-mail inicial... aquelas informações são justamente de um
> >>>>>>>> momento que o problema estava acontecendo.... você pode ver que
> dos 8
> >>>>>>>> Gb de RAM, apenas 3.5 em uso, 4.5 Gb livres.
> >>>>>>>> CPU's praticamente 99% idle. E o I/O em disco não achei os valores
> >>>>>>>> críticos...
> >>>>>>>> Monitorei essa máquina hoje por quase 5 horas, vasculhando
> problema e
> >>>>>>>> não consegui identificar. Faço o rotate dos log's todo dia à meia
> >>>>>>>> noite... neste servidor que estou usando como estudo do caso, o
> >>>>>>>> access.log nunca passou de 400 Mb. :-(
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Igor Luiz Oliveira de Souza
> >>>>>>>> Solic Tecnologia e Sistemas
> >>>>>>>> (77) 8829-7678
> >>>>>>>> igorluiz at solic.com.br
> >>>>>>>>
> >>>>>>>> 2010/1/2 Anderson Duarte<andersonrizada at gmail.com>:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>>>>> Hash: SHA1
> >>>>>>>>>
> >>>>>>>>> Toledo, Luis Carlos escreveu:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Quem é o DNS resolver desses proxies? Pois se houver gargalo no
> DNS
> >>>>>>>>>> ele
> >>>>>>>>>> afeta o proxie.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Eu ia responder justamente isso que o Toledo citou!
> >>>>>>>>> Certa vez eu tive um problema com DNS por usar proxy transparente
> pois
> >>>>>>>>> demorava a consulta causando um gargalo.
> >>>>>>>>> Depois que reconfigurei e passei a não mais usar o proxy
> transparente,
> >>>>>>>>> meus problemas acabaram. Mas como a maquina volta a funcionar do
> nada,
> >>>>>>>>> realmente pode ser o que o Alexandre falou sobre o access.log.
> >>>>>>>>> Verifique como o log é rotacionado nas maquinas que nunca deram
> >>>>>>>>> problemas e veja se faz igual nas outras, vc pode desabilitar o
> >>>>>>>>> access.log, mas se vc precisa dele pra algo como um relatorio
> tipo o
> >>>>>>>>> SARG, daí tem que configurar como irá rotacionar os logs.
> >>>>>>>>>
> >>>>>>>>> Agora uma duvida, quando a maquina estava com o rendimento baixo,
> e vc
> >>>>>>>>> deu uma monitorada no disco, cpu, memoria, etc....  não achou
> nada de
> >>>>>>>>> estranho ? Pois geralmente quando ele está rotacionando o log a
> >>>>>>>>> maquina sobe um pouco a CPU e o I/O de disco. Quanto tempo vc
> >>>>>>>>> monitorou a maquina ?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -----BEGIN PGP SIGNATURE-----
> >>>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux)
> >>>>>>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>>>>>>>>
> >>>>>>>>> iQEcBAEBAgAGBQJLP9L9AAoJEFifSKRkExpAiqUH+wRMaE5VAPLi4opN/sZ+rcjz
> >>>>>>>>> 45yO1nYXTe5IqZP2hQLXPW3uQV6mgvhMX6IcTJBMvtQ+yTCdlvbJtc3dKIKM9+Di
> >>>>>>>>> 8/h79Y3aaIWe3fKC8enng6TJB2KBoQ2NEYuM+uJ6LhZs8WfP6pAslZWKLYplpM4W
> >>>>>>>>> bOZQSdrVDkaGU5knam0RquhImZYcl/vnkCZP9jV8PySDGT/dZSda8u0t6otzv1ke
> >>>>>>>>> HZCSJ+M+wXQdalaNGkAiV64wsSIiKX3Nk3q2rd+fR4+LfU7xCaWT9SCWnbbOTJrg
> >>>>>>>>> Fck20Z9CuwtAf6B+G482bFG3RQF9gwlAUA0Grd95f01jkn/FMamhYDgUan9fqzM=
> >>>>>>>>> =4DUQ
> >>>>>>>>> -----END PGP SIGNATURE-----
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Sds.
> >>>>>
> >>>>> Alexandre Jeronimo Correa
> >>>>>
> >>>>> Onda Internet
> >>>>> www.onda.net.br
> >>>>>
> >>>>> IPV6 Ready !
> >>>>> www.ipv6.onda.net.br
> >>>>>
> >>>>> --
> >>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Igor Luiz Oliveira de Souza
> >>>> Solic Tecnologia e Sistemas
> >>>> (77) 8829-7678
> >>>> igorluiz at solic.com.br
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>