Em 26 de abril de 2012 16:36, Marcelo Gondim <gon...@bsdinfo.com.br>escreveu:
> Em 26/04/2012 15:59, Marcelo Gondim escreveu: > > Em 26/04/2012 15:37, Asstec escreveu: > >> Saul Figueiredo wrote: > >>> Minhas configurações de cache_dir e cache_men: > >>> > >>> cache_dir ufs /sarg/cache/ 19000 16 256 > >>> cache_mem 1024 MB > >> essas configurações não influenciam em nada na exec do reconf, tanto faz > >> se é i386 ou amd64 > >> > >> esquece aquele cálculo que alguém te sugeriu, que o cara está > >> confundindo e misturando as bolas > > Só pra constar aquele cálculo que sugeriram é desse "cara" aqui que > > misturou as bolas: > > http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram > > Agora você dizer que os devs do squid confundiram o cálculo é > > complicado. rsrsrsr > > > > Outra coisa esse cálculo faz muiiiita diferença e se fizer à bangú vai > > ter muitos problemas, sei porque já tive. Posso te dizer porque meu > > cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link > > de 1TBps. Não estou dizendo que esse possa ser o problema do nosso > Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. > Esse tipo de demora que ele está dizendo ainda acho que pode ser algo > relacionado com discos, filesystem. > > > amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar > > nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não > > teria nada à ver. > > Outra coisa dá uma olhada em todos os logs não só os squid, checa > > inclusive os discos pra ver se não está tendo problema com eles. Se > > puder dá um boot entra em single e passa um fsck nas partições também. > > Bem são algumas idéias. > > > >> aquele cálculo pode estar certo mas emn relação a RAM da máquina e não > >> aos parametros cache_dir e/ou cache_mem > >> > >> esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem > >> 1024 até é muito pouco > >> > >> seu problema de demora está em outro lugar, facilmente descobre dando um > >> tail no squid.log enquanto executa o reconfigure > >> > >> caso não encontra, aumente o debug level e observe > >> > >> > >> > >> > >> > >> > >> ------------------------- > >> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > ------------------------- > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks: 8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks: 3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- "Deve-se aprender sempre, até mesmo com um inimigo." (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
