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

[Igor Luiz Oliveira de Souza]

Oi Jean,

root at proxy:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/root              85G  6.9G   74G   9% /
tmpfs                 4.0G     0  4.0G   0% /dev/shm
/dev/sdb1             600G   53G  548G   9% /cache

Sobre limpar o cache... veja só, não lembro ao certo, mas você falando
acho que em outra ocasião isolada tive um problema como esse e
limpando o cache e reiniciando o Squid, acho que normaliza... se não
me engano acho que tratava esse problema dessa forma quando ele
acontecia no passado... mas isso quando usava caches de 200 ou 500 Mb,
que era rápido de re-alimentar.... mas com um cache desse, com mais de
50 Gb, posso fazer a título de análise, mas seria um prejuízo aguardar
todo o tempo de re-alimentação para voltar a subir os HIT's.
Se isso resolver, alguma idéia do que fazer para proteger a reincidência futura?

Valeu pela força,
-- 
Igor Luiz Oliveira de Souza
Solic Tecnologia e Sistemas
(77) 8829-7678
igorluiz at solic.com.br

2010/1/2 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
>