[389-users] Finger slow and optimizing performance

[Tim Hartmann]

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