[FUG-BR] squid -k reconfigure demorando muito

[Saul Figueiredo]

Em 26 de abril de 2012 16:36, Marcelo Gondim <gondim em 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
saulfelipecf em gmail.com
saul-felipe em hotmail.com