Print a (rate-limited) warning when UMA zone is full.

[Pawel Jakub Dawidek]

On Thu, Nov 29, 2012 at 10:30:07AM +0000, Robert Watson wrote:
> 
> On Thu, 29 Nov 2012, Pawel Jakub Dawidek wrote:
> 
> > I'd like to propose the following patch:
> >
> > 	http://people.freebsd.org/~pjd/patches/uma_warning.patch
> >
> > When UMA zone is created, one can add configure a warning that should be 
> > printed when UMA zone is full by calling:
> >
> > 	uma_zone_set_warning(socket_zone,
> > 	    "kern.ipc.maxsockets limit exceeded, please see tuning(7).");
> >
> > It was very easy to find and fix the problem when I saw messages on the 
> > console that kern.maxfiles limit is reached, but when I hit 
> > kern.ipc.maxsockets limit and started to get ENOBUFS errors it took me a 
> > while to figure out what to tune.
> >
> > This patch allows to configure advice for the use and give him some details 
> > in a very easy way. The warning printed on the console is rate-limited to 
> > one per second.
> 
> Just to follow up on some out-of-band communication -- this is a good idea, 
> but there was some concern about printf() under mutexes.  I'm not actually 
> that concerned about that case (we do it quite a lot for warnings and kernel 
> debugging), but it might be useful to consider using log() instead, so that it 
> ends up in the system log as well as on the console.

I'm happy with using log(9), but currently when log(9) is used, the
message is not printed on the console, it only ends up in the system
log. printf(9) on the other hand is printed on the console and is
appended to the system logs.

The only case where log(9) will actually log to the console, AFAIR, is
when syslogd is not working.

> For I while I've wondered if we need a spp to complement pps -- that is, 
> limiting printf()s to every (n) seconds, rather than (n) per second.  For 
> tunable warnings like this, it would be nice to limit them to once a minute or 
> similar.

Or change pps to ppm. I agree that getting these warning every second is
too aggressive.

> Finally, we should make sure that in all instances where we point at 
> tuning(7), it has something useful to say about the topic :-).

Yes, I am aware the warnings proposed in the patch are a bit too
optimistic:)

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20121129/0da24698/attachment.sig>