[Bug 642] Simultaneus logon take to much time
http://bugs.skolelinux.no/show_bug.cgi?id=642
------- Additional Comments From andreas@schuldei.org 2004-03-19 02:00 -------
some additional information:
the verbose (loglevel 1) and the shorter (loglevel 256) log are highly bloated
by additional lookups due to a "top" process doing lookups and the relevant
login process is hard to find.
http://www.netsys.com/nssldap/2001/02/msg00085.html
"There is a compatibility mode for initgroups()
lookups which would result in the entire group database being iterated over,
but that shouldn't be being used. You should see a query like:
(&(objectClass=posixGroup)(|(memberUid=sxw)(uniqueMember=uid=sxw,ou=...)))"
this is what we see in the 256 log:
filter="(&(objectClass=posixGroup)(|(memberUid=finnarne)
(uniqueMember=uid=finnarne,ou=People,dc=skole,dc=skolelinux,dc=no))).
we must conclude that the initgroup problem as described in the thread is
sloved, since the proper query is beeing used. the compatibility mode`s query
"(objectClass=posixGroup)" as such is not seen.
This is also supported by the fact that the initgroup patch went into
libnss-ldap in version 145, long before woody release version 186
http://packages.debian.org/stable/net/libnss-ldap
The slowness is therefore not to be attributed to a slow search algorithm of
libnss-ldap in the ldap database. Closer inspection of the 256'er log reveals
that the login bind is connection 25, and that all search queries executed
within that connection both query details about finnarne and also return their
results *right away*. the libnss-ldap process asks those details with one long
2 second delay inbetween. as far as slapd is concerned the login process is
handled within those 2 seconds.
The likely suspect for the delay is therefore not slapd but libnss-ldap or an
other process higher up in the caller chain.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Reply to: