Slapd Performance With Indexing

Test Environment

Test Description

Structure

First, we have to find out which data is mostly wanted. By this we then define the indexes for the demanded entries (attributes). An subsequent reindexing of the existing database and a test run will prove the expected advantages.

How to choose the Indexes

From earlier investigations we found a top 10 list for the most used queries. We use this information to define our indexes. The following list show examples for the from a 6h logging statistics from one BDII instance at CERN:

The script, which creates this output was provided by Valentin Vidic and can be found in the attachments (see below).

Occurence	Filter	Example for Filter
13805	(&(objectClass=GlueCluster)(GlueClusterUniqueID=Some_host))	(&(objectClass=GlueCluster)(GlueClusterUniqueID=ce108.cern.ch))
5505	(GlueSEUniqueID=Some_host)	(GlueSEUniqueID=t2-dpm-01.na.infn.it)
5310	(&(GlueServiceURI=*Some_host*)(GlueServiceType=srm_v1))	(&(GlueServiceURI=*srm.grid.sara.nl*)(GlueServiceType=srm_v1))
2503	(&(objectClass=GlueSA)(GlueSAAccessControlBaseRule=Some_VO))	(&(objectClass=GlueSA)(GlueSAAccessControlBaseRule=lhcb))
2047	(&(objectClass=GlueCE)(|(GlueCEAccessControlBaseRule=VO:Some_VO)(GlueCEAccessControlBaseRule=Some_DN)))	(&(objectClass=GlueCE)(|(GlueCEAccessControlBaseRule=VO:alice)(GlueCEAccessControlBaseRule=/C=CH/O=CERN/OU=GRID/CN=Latchezar Betev 7928)))
1396	(&(&(objectClass=GlueVOView)(GlueChunkKey=GlueCEUniqueID=Some_CE_unique_ID)(GlueCEAccessControlBaseRule=VO:Some_VO)))	(&(&(objectClass=GlueVOView)(GlueChunkKey=GlueCEUniqueID=ce114.cern.ch:2119/jobmanager-lcglsf-grid_2nh_lhcb)(GlueCEAccessControlBaseRule=VO:dteam)))
1383	(|(objectClass=GlueCESEBindGroup)(objectClass=GlueCESEBind))	(|(objectClass=GlueCESEBindGroup)(objectClass=GlueCESEBind))
1243	(&(objectClass=GlueSubCluster))	(&(objectClass=GlueSubCluster))
1047	(&(GlueServiceType=*)(GlueServiceAccessControlRule=Some_VO))	(&(GlueServiceType=*)(GlueServiceAccessControlRule=dteam))
571	(GlueCEUniqueID=Some_CE_unique_ID)	(GlueCEUniqueID=ares02.cyf-kr.edu.pl:2119/jobmanager-lcgpbs-alice)

In combination with logs we got on other days, we can determine these indexes:

ObjectClass
GlueSEUniqueID
GlueCEUniqueID
GlueSAAccessControlBaseRule
GlueCESEBindCEUniqueID
GlueSubClusterUniqueID
GlueCEAccessControlBaseRule

The New SLAPD Configuration

With the index list we can modify the configuration file of the slapd server in the following way:

...
database        ldbm
cachesize       30000
dbcachesize     30000000
dbnosync
suffix          "o=grid"
rootdn          "o=grid"
rootpw          secret
defaultaccess   read
directory       /opt/bdii/var/2171

index ObjectClass eq
index GlueSEUniqueID eq
index GlueCEUniqueID eq
index GlueSAAccessControlBaseRule eq
index GlueCESEBindCEUniqueID eq
index GlueSubClusterUniqueID eq
index GlueCEAccessControlBaseRule eq

After this, the index files have to be created by the command /usr/sbin/slapdindex. While running, the the database shouldn't be modified!

These are the files which where created in the database directrory:

-rw-------    1 root     root      1069056 Mar 22 17:01 objectClass.dbb
-rw-------    1 root     root       151552 Mar 21 16:16 GlueSEUniqueID.dbb
-rw-------    1 root     root       151552 Mar 21 16:16 GlueCEUniqueID.dbb
-rw-------    1 root     root        61440 Mar 21 16:16 GlueSAAccessControlBaseRule.dbb
-rw-------    1 root     root       151552 Mar 21 10:28 GlueCESEBindCEUniqueID.dbb
-rw-------    1 root     root        24576 Mar 21 16:16 GlueSubClusterUniqueID.dbb
-rw-------    1 root     root        61440 Mar 21 16:16 GlueCEAccessControlBaseRule.dbb

The Scenario

We use the most queried filter exampe

 (&(objectClass=GlueCluster)(GlueClusterUniqueID=ce108.cern.ch)) 

and submit up to 60 parallel ldapsearches from three machines.

Test Results

Belowone can find the average response time graphs for two test runs. The first one was firing against a non indexed OpenLDAP database, the second one against an indexed one.

The related data the graph is based on can be found in the attachments on this twiki page

The CPU Load

The Graph below shows the CPU load during both request bursts. The little bumb represent the load during RUN2, the heavy load (100%) during RUN1

The Disk I/O

The Graph below shows the disk load during both request bursts in KB/sec

The Network I/O

The Graph below shows the network I/O during both request bursts.

Conclusion

-- FelixNikolausEhm - 13 Apr 2007