Date: Sun, 5 May 2002 22:39:40 -0700 (PDT) From: Patrick Thomas <root@utility.clubscholarship.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Anthony Schneider <aschneid@mail.slc.edu>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: what causes a userland to stop, but allows kernel to continue ? Message-ID: <20020505223641.M86733-100000@utility.clubscholarship.com> In-Reply-To: <3CD5DF0E.481BBFA4@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Are NMBCLUSTERS and mbuf determined by 'maxusers' ? I have maxusers=512 ... comments ? When you suggest 'clamp the total number of sockets that are permittedto be open' ... how is this done - is there a sysctl that corresponds to "total number of sockets that are permitted to be open" ? I am also a little confused how this performance issue is solved by _lowering_ a tunable value - all of my problems up to this point (ran out of file descriptors, ran out of ptys, etc.) were solved by increasing them. Thank you for your help, PT On Sun, 5 May 2002, Terry Lambert wrote: > Anthony Schneider wrote: > > Livelock, maybe? Is there some sort of internal kernel semaphore table which > > might be getting filled up or something? I'd also like to find out more about > > this, but sadly, the machine is a remote one and I can't drop into ddb as > > suggested... > > Thanks you all very much. Hope this information is of use. > > -Anthony. > > More likely, you have run out of some non-renewable resource, > such as mbufs, and are in the midst of a deadly embrace deadlock > (e.g. as a result of having no mbufs to send responses or receive > acknowledgements which would free up mbufs currently held for TCP > sessions in progress, etc.). > > The easies way to see this is to periodically record vmstat -m > and netstat -m output to a disk file, and sync, in order to make > sure that it's recorded at the time you must reset. > > Then plot the information over time, up to the point of the failure, > and you will likely see the problem in gory detail. > > If it is something like mbuf starvation, then you should clamp the > total number of sockets that are permitted to be open at half the > maximum window size divided into the number of mbufs available, > minus 10% for a reserve. > > > In general, the "tuning" page is broken; a number of the things it > suggests tuning via systctl at run time are not actually tunable at > run time, only at boot time. Though at run time, they will remove > the top end limits, they will in fact not result in the reservation > of sufficient resource to meet those limits, as they would had they > been in effect at boot time, instead. > > In particular, increasing the number of open files permitted by > modifying "maxfiles" via sysctl at runtime will not add to the > prereserved amount of tcpcb's, inpcb's, or socket structures, > all of which could leave you starving for one of these objects, > or the mbuf's needed to support them, at runtime. > > It pays to understand the code before fiddling the numbers. ;^). > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020505223641.M86733-100000>