-----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@xxxxxxxxxxxxxx> 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-----
