Hi, I have some servers running running on 5.4-STABLE as of Apr 5th. I use nss_ldap for a userbase of currently about 24000 accounts (will be growing to approx 60000 in the next weeks). I don't use pam_ldap currently, because users only need to login by IMAP, POP, SMTP and FTP, for all of these services daemons are used which natively auth against the LDAP server. The more accounts there are in the LDAP directory, the longer the startup of "top" takes. With the current userbase top takes about 3-4 seconds to start (on a mostly idle Dual Xeon 2.8GHz with fast disks and local slapd). The startup time is not any different, sometimes I feel (did not try to measure) it's even longer, if I use "top -u" to not map uids. The running processes are only from a few uids, all the LDAP users usually don't have processes running under thier IDs. Any ideas, why this is happening? Will I need 10 seconds, when there are 60000 accounts in LDAP? :-) - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
In the last episode (Apr 25), Oliver Brandmueller said:> I have some servers running running on 5.4-STABLE as of Apr 5th. I > use nss_ldap for a userbase of currently about 24000 accounts (will > be growing to approx 60000 in the next weeks). I don't use pam_ldap > currently, because users only need to login by IMAP, POP, SMTP and > FTP, for all of these services daemons are used which natively auth > against the LDAP server. > > The more accounts there are in the LDAP directory, the longer the > startup of "top" takes. With the current userbase top takes about 3-4 > seconds to start (on a mostly idle Dual Xeon 2.8GHz with fast disks > and local slapd). > > The startup time is not any different, sometimes I feel (did not try > to measure) it's even longer, if I use "top -u" to not map uids. The > running processes are only from a few uids, all the LDAP users > usually don't have processes running under thier IDs.You can benchmark top by running "time top -d1", which will print one page then immediately exit.> Any ideas, why this is happening? Will I need 10 seconds, when there > are 60000 accounts in LDAP? :-)Try editing /usr/src/usr.bin/top/Makefile, add -DRANDOM_PW, and rebuild. That should probably be the default on FreeBSD anyway. -- Dan Nelson dnelson@allantgroup.com
Hi,> Any ideas, why this is happening? Will I need 10 seconds, when there are > 60000 accounts in LDAP? :-)Have you set your indexes correctly? This may result in a huge speedup. I use (this is only for about 180 accounts, but NSS works instantly): # Indices to maintain index objectClass eq index cn sub,pres,eq index uid,uidNumber,gidNumber,homeDirectory pres,eq Also, have you tried truss(1) or ktrace(1) on the process? It might help you try to see if the LDAP server is just being slow, or the LDAP client is. -- Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050426/44471177/attachment.bin
On Mon, 2005-04-25 at 12:59 +0200, Oliver Brandmueller wrote:> Hi, > > I have some servers running running on 5.4-STABLE as of Apr 5th. I use > nss_ldap for a userbase of currently about 24000 accounts (will be > growing to approx 60000 in the next weeks). I don't use pam_ldap > currently, because users only need to login by IMAP, POP, SMTP and FTP, > for all of these services daemons are used which natively auth against > the LDAP server. > > The more accounts there are in the LDAP directory, the longer the > startup of "top" takes. With the current userbase top takes about 3-4 > seconds to start (on a mostly idle Dual Xeon 2.8GHz with fast disks and > local slapd).FWIW, I don't think this is related to LDAP as such. I have a machine bound to NIS with ~19000 entries in the passwd file. Top takes ages to start up. The problem is in machine.c - it iterates over every user in the passwd file to figure out what how many characters longest username may be. It's nasty and to be honest I think it can/should just be removed. Try the attached patch just to prove that this is the cause in your case too. A while back, there was talk of a FreeBSD libc name cache daemon, but I can't seem to find any reference to it now (I seem to remember the website was within .ru, if it helps anyone find it) - though I'm not sure it would help in this context or even if it's really the correct way to mask the bug. Gavin -------------- next part -------------- A non-text attachment was scrubbed... Name: top-machine.diff Type: text/x-patch Size: 641 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050427/183a46f4/top-machine.bin