Re: [squid-users] Opinions sought on best storage type for FreeBSD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michel,

I am coming back to the topic of Squid restarting itself when the load increases and the number of clients requests goes upto 100-200 per second.

After digging around cache.log of my Squid boxes, I am seeing the following messages. And I think it's related to diskd rather than the overall memory and sysctl tunables of my FreeBSD machines.

2007/08/13 22:58:41| clientReadRequest: FD 466 (202.79.62.1:10231) Invalid Request
2007/08/13 22:58:43| assertion failed: diskd/store_io_diskd.c:384: "!diskdstate->flags.close_request"
2007/08/13 22:58:47| Starting Squid Cache version 2.6.STABLE13 for i386-unknown-freebsd6.0...
2007/08/13 22:58:47| Process ID 10145
2007/08/13 22:58:47| With 16384 file descriptors available
2007/08/13 22:58:47| Using kqueue for the IO loop
2007/08/13 22:58:47| DNS Socket created at 0.0.0.0, port 56931, FD 5

Well I don't know why diskd is giving this error. Or maybe my compile and sysctl tunables options are not correct. Maybe as Henrik mentioned, it's the bug #761 of diskd which is causing this.

I am seeing this error both on squid-2.6.9 and squid-2.6.13.

Will upgrading to Squid-2.6.14 make the situation better?
Or do you have other tweaks or hacks for FreeBSD/Diskd which might solve this problem?

Thanking you...

On Mon, 13 Aug 2007 08:07:44 -0300 (BRT)
"Michel Santos" <michel@lucenet.com.br> wrote:

>
> Tek Bahadur Limbu disse na ultima mensagem:
> >>
> >> what size is your link?
> >
> > For each proxy, the link is burstable upto to 15 mbps. But they are
> > grouped together in different groups. We have 6 groups. Each group has
> > bandwidth ranging from 5 mbps to 20 mbps. However since our link comes via
> > satellite, the proxies starts building a large number of mbufs especially
> > when our uplink gets saturated. Since it's a satellite link, bandwidth is
> > never enough no matter how big we are subscribing. We still have some time
> > to go (maybe months, or years) before we get it from a fiber link.
> >
> >>
> >> Sure this is not related to your crash and to your link either but
> >> somaxconn is the queue size of pending connections and not the number of
> >> connections and you are probably setting this far too high. somaxconn as
> >> 1024 or max 2048 would be more reasonable and nmbcluster I would not set
> >> higher than 128 or 256k
> >>
> >> if you eat that up you have other troubles and increasing this values
> >> does
> >> not solve them I guess
> >
> > Well I am using nmbcluster = 256000 on some of my FreeBSD-6.2 machines
> > because they don't support setting the nmbcluster to 0. Well let me try
> > setting somaxconn to 2048.
>
> I like to suggest again starting a clean system like said in a former msg
> and observe and then check value for value instead of mixing it all up at
> once
>
>
>
> > - From my observation in recent months, the mbufs value has not crossed
> > 120K. I will probably use 128K or 256K. I read an article regarding
> > setting somaxconn=32768 to help stop SYN flooding.
> >
> > http://silverwraith.com/papers/freebsd-ddos.php
>
>
> who am i to understand miracles? without saying any else I suggest you
> compare the man page or tuning what describes somaxconn and what the
> author claims it is and figure out about the other statements ...
>
>
> > In your opinion, what's wrong with setting nmbcluster to 0 since, in
> > this way, I never run out of mbufs?
>
>
> sorry if came over a wrong impression that I want to lecture or something,
> I am not saying it is wrong (how would I know?), I am only changing ideas
> here ok and am saying that I would do it different and what is my opinion
>
>
>
> michel
> ...
>
>
>
>
> ****************************************************
> Datacenter Matik http://datacenter.matik.com.br
> E-Mail e Data Hosting Service para Profissionais.
> ****************************************************
>
>

- --

With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGwU9RfpE0pz+xqQQRAr89AKDBowFVvbHYulhK1+87pbymMwHu4ACfTQ9M
kkjrWd2GKMqne3FaSHRSzN8=
=ZyNB
-----END PGP SIGNATURE-----
Received on Tue Aug 14 2007 - 00:44:21 MDT