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

Igor Luiz Oliveira de Souza igorluiz at solic.com.br
Sun Jan 3 22:11:10 -02 2010 

Oi Renato,

Sim... rodei um vmstat na hora do problema... tá no e-mail da
descrição do problema:
=> 'vmstat' COMMAND OUTPUT:
--------------------------------
root at proxy:/usr/local/squid/etc# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 4655236 527384 1993244    0    0    12    37    8   24  0  0 98  1
 0  0      0 4654980 527384 1993292    0    0     0   504 4612  368  0  0 99  0
 0  0      0 4654848 527424 1993524    0    0    40     0 4816  671  0  0 98  2
 0  0      0 4654724 527436 1993712    0    0   168     0 4740  522  0  0 99  1
 0  0      0 4654352 527448 1993876    0    0     0    76 4818  487  0  0 100  0
 0  0      0 4654344 527460 1993976    0    0     4     0 4718  500  0  0 100  0
 0  0      0 4654220 527468 1994120    0    0    24   588 4579  398  0  0 99  1
 0  0      0 4653848 527480 1994332    0    0   104     0 4853  627  0  0 99  1
 0  0      0 4653360 527500 1994532    0    0     0     0 4909  683  0  0 100  0
 0  0      0 4653212 527516 1994716    0    0     0    40 4877  447  0  0 100  0
 0  0      0 4652964 527536 1994732    0    0    12     0 4721  518  0  0 100  0
 0  0      0 4652964 527548 1994800    0    0    16   820 4810  708  0  1 99  1
 0  0      0 4652716 527572 1994936    0    0    20     0 4696  628  0  0 99  1

A idéia do "diskd" para o cache_dir é interessante... Costumava antes
usar diskd com estabilidade... mas depois de ver alguns relatos
recomendando tunning como aufs, passei a usá-lo... o que intriga é que
aqueles outros 11 servidores que estão rodando bem, sem qualquer
ocorrência do problema, muitos deles com um volume de cache acumulado
muito maior, maior número de requets/sec, etc...  Mas o "diskd" é uma
boa opção a se avaliar... se chegar ao ponto de precisar recriar o
cache nesse estudo, vou testar com o diskd.

O DNS nesse proxy já é totalmente dedicado ao squid... ninguém mais
faz consultas através dele, apenas o squid.

O high memory é via PAE mesmo, pois o Linux é 32bits. Nunca tive
histórico de problemas...
Mas de qualquer forma, quando o problema começou a acontecer, eu não
havia ativado o highmemory ainda... a máquina só estava reconhecendo 3
Gb de RAM...

A escolha do da versão 2 do Squid é apenas por ter tido problemas de
estabilidade quando testei o 3, ainda na beta... acabei deixando o 2
mesmo.

Mas valeu mesmo pelas dicas... a idéia do "diskd" então me interessou
muito... vou verificar.

Abraços,
-- 
Igor Luiz Oliveira de Souza
Solic Tecnologia e Sistemas
(77) 8829-7678
igorluiz at solic.com.br

2010/1/3 Renato Frederick <frederick at dahype.org>:
> 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

More information about the gter mailing list