[389-users] Finger slow and optimizing performance

Tim Hartmann hartmann at fas.harvard.edu
Fri Jun 26 15:23:55 UTC 2009


Rich Megginson wrote:
> Andrey Ivanov wrote:
>> Hi,
>>
>>
>> There may be several attributes of interest to you as far as the
>> memory consumption is concerned
>> (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)
>> :
>> nsslapd-dbcachesize
>> nsslapd-cachememsize for every backend (by default, your data is in
>> cn=userRoot,cn=ldbm database,cn=plugins,cn=config)
>> nsslapd-import-cachesize (used only during ldif import)
> Start with nsslapd-cachememsize - make that as large as possible and
> minimize nsslapd-dbcachesize
>>
>> You can adjust the corresponding values by monitoring the attributes
>> like currententrycachesize or entrycachehitratio of 
>> cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
>> (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_Plug_in_Attributes-Database_Attributes_under_cnmonitor_cnldbm_database_cnplugins_cnconfig)
>>
>>
> You can also use the logconv.pl script to examine the access log to
> see what types of searches are being done and which are not indexed
> properly.
>

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? 

Thanks!

Tim




More information about the 389-users mailing list