[FUG-BR] squid lento

[João Carlos Mendes Luís]

Lutieri G. wrote:
> Em 28/08/07, João Carlos Mendes Luís<jonny at jonny.eng.br> escreveu:
>   
>> Abaixo:
>>     
>>> acl sitesthorga url_regex -i "/usr/local/etc/squid/xyz/sitesthorga.txt"
>>> acl sitesthorga_eng url_regex -i "/usr/local/etc/squid/xyz/sitesthorga_eng.txt"
>>> acl msn_chineses url_regex -i gateway.messenger.
>>> acl msn_chineses url_regex -i login.live.com
>>> acl msn_chineses url_regex -i gateway.dll
>>> acl msn_chineses url_regex -i msn.com
>>> acl palavra_radio url_regex -i radio
>>> acl site_biruta url_regex -i birutadosul
>>> acl site_votorantim url_regex -i webmail.votorantim.com.br
>>> acl site_votorantim url_regex -i portal.votoran.com.br
>>> acl site_votorantim url_regex -i portal.votorantim-cimentos.com.br
>>> acl palavra_direito url_regex -i direitodoestado.com
>>> acl malwares url_regex -i "/usr/local/etc/squid/xyz/malware.txt"
>>> acl bloqueados url_regex -i "/usr/local/etc/xyz/xyz/bloqueados.txt"
>>> acl liberados url_regex -i "/usr/local/etc/xyz/xyz/liberados.txt"
>>>
>>>       
>> Experiencia de quem já usou muito o squid: Evite usar milhares de
>> expressoes regulares.
>>
>> Elas consomem CPU.  Se voce puder descrever a regra sem expressao
>> regular, o desempenho será muito melhor
>>
>> Experiencia propria, da pior maneira possível...   :-(
>>
>>     
>>> Volta e meia aparecem mensagens assim no cache.log:
>>> httpAccept: FD 41: accept failure: (53) Software caused connection abort
>>>
>>>
>>> Eu sei que tem bastante regras usando url_regex, mas não pode ser por
>>> causa disso.
>>>
>>>       
>> É sim...   ;-)
>>     
>
> Tá tudo bem... Deixa mais ocupado o processador mas não a ponto de
> demorar pra carregar o logo do google nas estações e gradativamente ir
> piorando.
>   

Foi justamente isso que me aconteceu.  Mas pelo jeito o seu problema 
acontece mais rápido, e também acontece sem as ACLs.

Os pontos em que o squid é mais exigido são a rede e o disco, 
principalmente disco.

> Sem contar que agora, no BSD, eu tenho uma máquina rodando o squid
> muito mais potente do que a que está em produção rodando linux. E no
> linux não apresenta lentidão nenhuma.
>   

O HD é SCSI ou IDE?
>   
>> Ainda: Se voce usou a gnu-regex para compilar, tente tirar.  Se não
>> usou, tente colocar.  O desempenho varia...
>>
>>     
>>> Tenho uma partição de 10Gb pra cache.
>>>
>>>       
>> Mais importante que o tamanho da partição é onde ela está.  Qual o tipo
>> de disco?  Qual a velocidade do disco?  Tem mais alguma partição no
>> disco, ou é exclusivo do squid?
>>
>> Verifique que a partição está com softupdates e montada com noatime.
>>     
>>> Juro que não sei o pq da lentidão. Quando digitou: squidclient
>>> mgr:info me retorna que tem em torno de 40 clientes e jah fica
>>> lento.... Mas no outro servidor antigo tá rodando super bem com 500
>>> usuários.
>>>
>>>       
>> Para aguentar 10G de disco, ele tem que ter uma boa quantidade de RAM
>> não alocada para cache.
>>
>> Veja aqui: http://www.comfsm.fm/computing/squid/FAQ-8.html#ss8.1
>>
>> Importante: Cheque de tempos em tempos e tenha certeza que o squid não
>> está indo para o swap.
>>
>>     
>>> Preciso de ajuda!
>>>
>>>       
>> Outra dica:
>>
>> cache_dir ufs /cache 8000 16 256
>>
>> Tente mudar de ufs para aufs ou ainda melhor, diskd.
>>
>> E altere o tamanho dos diretórios.  Deixe os dois níveis com o mesmo número de entradas.  Pode ser 256/256.  Para calcular o tamanho ótimo, deixe o cache encher, e conte quantos arquivos estão no cache.  Depois tire a raiz cúbica, e escolha um numero inteiro um pouco maior que esse valor.  Motivação: dividir igualmente o número de entradas (ou seja, o tamanho) de cada diretório no path.
>>
>>     
> Estou alterando agora para diskd. Dois diretórios dentro de uma mesma
> partição. Cada um com 4066 MB.  E a partição total tem 10GB. Ficou
> assim:
>
> cache_dir diskd /cache/0 4096 256 256 Q1=72 Q2=62
> cache_dir diskd /cache/1 4096 256 256 Q1=72 Q2=62
>
> Alguma objeção?
>   

Tá ótimo.  De vez em quando monitora o tamanho das filas, para ver se 
tem que aumentar alguma coisa.

> Vou rodar assim, e fazer os cálculos que mencionastes.
>   

Não que isso resolva o seu problema, mas é um lugar para espremer mais 
desempenho.

>   
>> ...
>>
>> Finalmente:
>>
>> httpAccept: FD 41: accept failure: (53) Software caused connection abort
>>
>> Google it, e ache a palavra do desenvolvedor:
>>
>> http://www.squid-cache.org/mail-archive/squid-users/200202/0406.html
>>
>>     
> Já tinha caído aí googling. Me passei e não vi que era um desenvolver
> que tinha escrito. E continuei em busca de uma resposta. Sem contar
> que na versão do linux nunca apresentou essa mensagem. Por isso
> continuei minha busca...
>   

Pode ser que o abort tenha sido conseqüência do problema real.

>> .....
>>
>> Mas em um email seu depois deste:
>>
>> Ontem mesmo removi a autenticação e todas ACL's e continuou com o problema....
>>
>> O mesmo problema?  O uso de CPU do squid deve ter melhorado para bem menos que 50%.
>>
>> ...
>>     
> Sim, o mesmo problema! Apesar de a CPU ter sentido a que tiraram um
> peso, não muito grande, das costas dela, a lentidão continuou.
>   

Mas dessa vez com bastante sobra de CPU, certo?

Voce já disse que o shell continua legal, então descarta minha próxima 
sugestão de problemas no switch (duplex/nao-duplex, por exemplo).

Acima disso, talvez você tenha que aumentar a depuração e descascar 
bit.  Eu iria até o nível do strace/ktrace para achar o problema.

Pergunta: O systat -v não acusa excesso de acesso a disco, acusa?

                                        Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br