[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 01:18:53 -02 2010 

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
>

More information about the gter mailing list