Date: Wed, 09 Jan 2008 18:35:47 +0000 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: David Frascone <dave@frascone.com> Cc: freebsd-current@freebsd.org Subject: Re: Small patch to fix top in large NIS environments Message-ID: <1199903747.70812.43.camel@buffy.york.ac.uk> In-Reply-To: <9cf5ced20801090915i3df2d4a1lc057a38b20fc5ac2@mail.gmail.com> References: <9cf5ced20801090915i3df2d4a1lc057a38b20fc5ac2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2008-01-09 at 12:15 -0500, David Frascone wrote: > The -u flag to top is supposed to limit uid lookups. But, it was still > spinning through the entire password database with while (getpwent()). At > Cisco, which has a fairly large NIS database, this takes forever, and top > never starts. > > I filed this bug to address it: > http://www.freebsd.org/cgi/query-pr.cgi?pr=119490 > > The attached patch fixes it. This is my first submission, so let me know if > this is the proper order, etc, to post the patches (i.e. file the bug, the > post a fix) This is a longstanding bug, sadly. bin/20799 seems to be the first to mention it, and is over 7 years old now. Every system I deploy at work has to have top(1) patched to avoid this. I think your solution of not sizing the usernames when -u is specified is a sensible one, although I think some thought really needs to be put into whether sizing is necessary at all - maybe the solution is to just limit the username field to 8 or 10 characters or so, and either trim longer names or show them as userids. Parsing a huge (in my case ~25,000 users) password map when top is run seems stupid, especially given that many invocations of top are at exactly the time when significant extra load on a system is not a good idea. It would probably be best to submit your patch as a followup to PR bin/89762. Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1199903747.70812.43.camel>