Rich Megginson wrote: > Tim Hartmann wrote: >> >>> >> >> So after playing with logconv a bit, it looked like finger was making >> this call in the logs... >> >> [26/Jun/2009:10:59:36 -0400] conn=283289 op=-1 fd=80 closed - B1 >> [26/Jun/2009:10:59:36 -0400] conn=283289 op=2 RESULT err=11 tag=101 >> nentries=0 etime=1 notes=U >> [26/Jun/2009:10:59:35 -0400] conn=283289 op=2 SRCH >> base="ou=really,ou=long,o=name,dc=school,dc=edu" scope=2 >> filter="(objectClass=posixAccount)" attrs="uid userPassword uidNumber >> gidNumber cn homeDirectory loginShell gecos description objectClass" >> [26/Jun/2009:10:59:35 -0400] conn=283289 op=1 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [26/Jun/2009:10:59:35 -0400] conn=283289 op=1 SRCH >> base="ou=systems,ou=services,o=hascs,dc=fas,dc=harvard,dc=edu" scope=2 >> filter="(&(objectClass=posixAccount)(uid=foo))" attrs="uid userPassword >> uidNumber gidNumber cn homeDirectory loginShell gecos description >> objectClass" >> [26/Jun/2009:10:59:35 -0400] conn=283289 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="" >> [26/Jun/2009:10:59:35 -0400] conn=283289 op=0 BIND dn="" method=128 >> version=3 >> [26/Jun/2009:10:59:35 -0400] conn=283289 fd=80 slot=80 connection from >> 1.2.3.4 to 4.3.2.1 >> >> >> >> But even after indexing "uid userPassword uidNumber gidNumber cn >> homeDirectory loginShell gecos description objectClass" finger still >> responds slower then it does on comparison to the older openLDAP >> servers... where we don't do indexing on all of these attributes, AND >> still claims that I'm running an search that hasn't been indexed! I'm >> I missing something glaringly obvious? > You only need to index the attributes used for searching: > (&(objectClass=posixAccount)(uid=foo)) > You need an equality index on objectClass (which should already be > there, it is one of the default indexes) and an equality index on uid > (again, should already be there). > Ok, thats cool, those are both being indexed correctly.... > The problem is this: > [26/Jun/2009:10:59:36 -0400] conn=283289 op=2 RESULT err=11 tag=101 > nentries=0 etime=1 notes=U > [26/Jun/2009:10:59:35 -0400] conn=283289 op=2 SRCH > base="ou=really,ou=long,o=name,dc=school,dc=edu" scope=2 > filter="(objectClass=posixAccount)" attrs="uid userPassword uidNumber > gidNumber cn homeDirectory loginShell gecos description objectClass" > > The notes=U and err=11 mean that either the lookthrough limit has been > exceeded, or you need to increase your nsslapd-idlistscanlimit: > http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html#Configuration_Command_File_Reference-Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig-nsslapd_idlistscanlimit > > > This is not a good search anyway - the client is basically asking for > all entries that match objectClass=posixAccount which could be > thousands or more - what does the client intend to do with all of > those entries? > Thats apparently the search that "finger foo" on RHEL 5.2 generates! "finger foo" on Ubunutu 8.04 responds notibly faster, so I'm assuming that it's generating a different search... hmmm -- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
