My servers have >80k accounts via nss_ldap. Startup of top is very slow, because top read the whole list of system users to find out which is the longest username. This takes several seconds for starting up top on an idle machine of decent speed. My current patch replaces the username advance code if a variable is defined at compile time. I suggest dropping the current behaviour completely, because the routine is for cosmetic changes to top output only while really being a pain in the ass if you have lots of users. How-To-Repeat: put 80k users on your system (probably use a slow user database like LDAP or NIS) and start top.
This is still a problem with 6.2-STABLE. On a 2.2GHz amd64 machine with ~20,000 NIS users, "top -b" takes 74 seconds before displaying any output and generates significant load on the NIS servers. wiggum# time top -b last pid: 1742; load averages: 0.00, 0.00, 0.00 up 36+03:20:25 15:39:47 32 processes: 1 running, 31 sleeping Mem: 82M Active, 191M Inact, 108M Wired, 213M Buf, 1498M Free Swap: 3072M Total, 3072M Free [process list snipped] 0.243u 0.719s 1:14.88 1.2% 60+1253k 0+0io 0pf+0w Gavin
This is a duplicate of PR bin/20799, although this one contains a more complete patch. This PR should remain open, 20799 should be closed.
We use similar patch on our system. I think the real solution is cached(8) in CURRENT.
Using cached(8) is only a partial solution though, as the first time top(1) is run the entire nismap will have to be pulled from the NIS servers. In my example where it took 74 seconds, most of the delay is probably down to the relatively slow NIS servers. cached(8) won't help with that, for the first run of top(1) at least.
Responsible Changed From-To: freebsd-bugs->edwin Grab it on the evneing of the 3.8b1 import for evaluation.
the issue seems to be that top reads in the entire list of username, because it calculates the legth of the username with the most characters in it. a solution would be that top only calculates the length of the usernames with active processes running. during each refresh of top however that needs to be re-calculated. still i believe that should be faster than the way top makes up the length of the USERNAME column atm. a more drastic solution would be to use a fixed width of the username column. how about 16 characters? that should be enough in a standard envirement to distinguish between each username. of course SUPERDUPERAMASINGUSER1 and SUPERDUPERAMASINGUSER2 wouldn't be distinguishable, but i guess keeping usernames sensible should be the admin's responsibility. cheers. alex
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
A commit references this bug: Author: eadler Date: Sun May 20 23:19:10 UTC 2018 New revision: 333945 URL: https://svnweb.freebsd.org/changeset/base/333945 Log: top(1): set max username length based on system constant This changes previous behavior of calculating it at startup based on the current max username length. This is done because: - it is in theory possible for the max length to change at run-time (e.g., a new user is added after top starts running) - on machines with many users this delays startup significantly PR: 20799 PR: 89762 Reported by: ob@e-Gitt.NET Reported by: wkwu@Kavalan.csie.NCTU.edu.tw Reported on: 2000-08-23 and 2005-11-30 Changes: head/usr.bin/top/machine.c head/usr.bin/top/machine.h head/usr.bin/top/top.c head/usr.bin/top/username.c
I've removed the "find max username length" code so this should be solved. Thanks for your submission.