Date: 23 Jan 2002 19:22:09 +0100 From: Lars Erik Gullerud <lerik@kq.no> To: Brian McGovern <mcgovern@spoon.beta.com> Cc: qa@FreeBSD.ORG Subject: Re: 4.5-RC2 kernel, m_clalloc failed Message-ID: <1011810129.75400.43.camel@elmer.i.eunet.no> In-Reply-To: <200201231753.g0NHrR912181@spoon.beta.com> References: <200201231753.g0NHrR912181@spoon.beta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, I got another reply (off-list) that the default socketbuffer sizes have increased a lot from 4.4 to 4.5 so that more clusters are used up pr. connection. Yes, the old 4.4 install had 8192 nmbclusters and worked fine. The 4.5 auto-tuned to 8640, and that obviously turns out not to be enough. So, as you correctly say, it is simply a case of mis-tuning by me - since I did not know the amount of mbufs being consumed was apparently higher. With a manually configured kernel (maxusers=256 and nmbclusters=65536 - just to be on the safe side) everything is working fine. Sorry for taking up anyone's time with this. Rgds, Lars Erik On Wed, 2002-01-23 at 18:53, Brian McGovern wrote: > Just one other datapoint... My 768MB 1.2GHz Athlon, set with maxusers to 64, > had 1536 available under 4.4. > > So, therefore, based on your ~8600 value, the system tuned itself to far more > than 64 users. > > -Brian > > > > I moved one of our shoutcast streaming servers over to 4.5-RC2 during > > the weekend to test it in a high network load environment. It was > > installed "fresh" on a clean system with an FTP install, i.e. not an > > upgrade from the old 4.4 install. > > > > After being in operation for just a few hours the server started logging > > these messages continously: > > > > Jan 23 14:34:41 disrv01 /kernel: m_clalloc failed, consider increase > > NMBCLUSTERS value > > Jan 23 14:34:41 disrv01 /kernel: fxp0: cluster allocation failed, packet > > dropped! > > Jan 23 14:34:42 disrv01 last message repeated 850 times > > > > The server had to be rebooted in order to function properly again, > > network connectivity was basically gone until it was rebooted. After > > reboot it again functioned for a few hours and then the same thing > > happened. > > > > The server is running 5 instances of the shoutcast server (original > > sc_serv binary from shoutcast, not icecast) on 5 separate TCP ports. The > > load had been steady between 400 and 500 concurrent TCP streams @ > > 128kbit for the whole 24 hours, and was at apx. 450 streams served when > > this error hit. Nothing else is running on this server. > > > > Kernel was recompiled for this machine after install, so not a GENERIC > > kernel, maxusers was set to 0 to test the auto-allocation. The > > NMBCLUSTERS as reported in kern.ipc.nmbclusters=8640. This is a P3-800 > > 512MB RAM box, who has been running steadily at a lot higher loads than > > this for a long time on 4.4-STABLE (750 streams max), so I'm assuming > > it's an issue introduced in 4.5. Unless it's just my stupidity and > > something just needs to be configured differently - maybe I should avoid > > the maxusers=0 and set some table sizes manually or something? > > > > I don't know what kind of info you might require, I'm not really much of > > a "kernelhacker", but I hope you fix whatever the prob is before > > 4.5-RELEASE or I'll have to stay on 4.4 for our streaming boxes. > > > > Regards, > > Lars Erik Gullerud > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-qa" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-qa" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-qa" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1011810129.75400.43.camel>