[FUG-BR] squid lento
Lutieri G.
lutierigbtrabalho em gmail.com
Terça Agosto 28 16:47:53 BRT 2007
Em 28/08/07, João Carlos Mendes Luís<jonny em jonny.eng.br> escreveu:
> Lutieri G. wrote:
> > Em 28/08/07, João Carlos Mendes Luís<jonny em 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...
SCSI disco SAS.
O problema tem que ser com ele.
> >>
> >>
> >>> 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?
>
exato
> 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?
>
tem algo estranho no ar:
3 users Load 0.00 0.00 0.00 Aug 28 16:41
Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER
Tot Share Tot Share Free in out in out
Act 37280 8164 78496 9420 3727752 count
All 142784 11080 20822552 14792 pages
zfod Interrupts
Proc:r p d s w Csw Trp Sys Int Sof Flt cow 8218 total
1 51 1699 11 1200 621 1 1 78536 wire 14: ata
27404 act 6 19: ohc
0.2%Sys 0.1%Intr 0.0%User 0.0%Nice 99.7%Idl 33748 inact 5 24: em2
| | | | | | | | | | 7240 cache 25: em3
3720512 free 9 26: em0
daefr 6 27: em1
Namei Name-cache Dir-cache prcfr 196 28: mpt
Calls hits % hits % react 1999 cpu0: time
1253 343 27 pdwak 1999 cpu1: time
pdpgs 1999 cpu2: time
Disks da0 da1 cd0 pass0 pass1 pass2 intrn 1999 cpu3: time
KB/t 7.43 0.00 0.00 0.00 0.00 0.00 219632 buf
tps 196 0 0 0 0 0 48 dirtybuf
MB/s 1.42 0.00 0.00 0.00 0.00 0.00 100000 desiredvnodes
% busy 99 0 0 0 0 0 1867 numvnodes
165 freevnodes
Não sei se vai ser possível entender. Mas olha ali no disco da0 tah
trafegando 1.24 MB/s e tah 99% busy.
Isso tá muito errado né?!
Vou desativar o espelhamento via hardware pra testar...
> Jonny
>
> --
> João Carlos Mendes Luís - Networking Engineer - jonny em jonny.eng.br
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
Att.
Lutieri G. B.
Mais detalhes sobre a lista de discussão freebsd