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... >> >> >>> 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 - [EMAIL PROTECTED] ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
