bin/89762: [patch] top(1) startup is very slow on system with many users

Gavin Atkinson gavin.atkinson at ury.york.ac.uk
Fri May 4 15:46:05 UTC 2007


On Fri, 2007-05-04 at 18:03 +0300, Giorgos Keramidas wrote:
> Can you truss/ptrace top at the time?  I think it's trying to find the
> longest username string, to align the USERNAME column, and it queries
> the NIS server for *all* users.

This is exactly what it's doing - the code in question i around line 240
of machine.c:

        while ((pw = getpwent()) != NULL) {
                if (strlen(pw->pw_name) > namelength)
                        namelength = strlen(pw->pw_name);
        }

Obviously, this also generates significant network traffic.  All of my
machines have this #if 0'd out and replaced with "namelength = 8"

I've just noticed another duplicate, PR bin/98693, also uses the same
hack.

> If that is the case, you should see a significant speedup when top runs
> with the -u option (but lose the functionality of seeing the username).

This code seems to still be run with the -u option.

> We could probably 'trim' long usernames in the USERNAME column and add
> a character like '>' shown below:
> 
> ------------------------------------------------------------------------
>   PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME    CPU COMMAND
>  4783 giorgosker>   1  96    0   294M 38244K CPU0   0  57:07  1.22% Xorg
> 22634 giorgosker>   1  96    0 11452K  9868K select 1   0:05  0.93% emacs
> 19084 giorgosker>   1  96    0  7256K  4176K select 0   2:49  0.88% xterm
>   960 root          1  96    0  3160K   864K select 0  12:51  0.00% powerd
> ------------------------------------------------------------------------
> 
> and keep a fixed length for the USERNAME column, but I am not sure if
> this would be an acceptablle UI change for top(1).

This may be sensible.  I don't think it's realistic to waste MAXNAMELEN
columns on everyone's display, but the current code really hurts any
setup with lots of users or slow NIS/LDAP servers.

Gavin


More information about the freebsd-bugs mailing list