Em 28/08/07, João Carlos Mendes Luís<[EMAIL PROTECTED]> escreveu: > Lutieri G. wrote: > > Em 28/08/07, João Carlos Mendes Luís<[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] > > ------------------------- > 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. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
