12.9. Indexing Your Database

Problem

You noticed there are some indexing options in slapd.conf—what's that all about? Will they make your directory go faster?

Solution

Indeed they will. Indexing attributes that are frequently searched for will speed up performance. Here are some sample indexes for different uses:

	#always have this one
	index objectClass eq

	#for common name searches
	index cn,sn,uid pres,eq,sub

	#email address searches
	index mail pres,eq

These go into slapd.conf.

Discussion

If you change the index settings while slapd is running, an internal task will automatically run and generate the new indexes. You don't need to explicitly regenerate the indexes. However, if slapd is stopped before the indexing task is finished, you'll have to manually generate the new indexes with the slapindex command:

	# /etc/init.d/slapd stop (Debian)
	# /etc/init.d/ldap stop (Fedora)
	# slapindex

When it's finished, restart OpenLDAP. If you have a large directory, this process will take a few minutes.

Indexing increases the size of your id2entry file. The larger your database and the more indexes you have, the bigger this file will grow. This post from the OpenLDAP-devel list (http://www.openldap.org/lists/openldap-devel/200510/msg00131.html) says:

For my test database with 360 MB input LDIF and 285,000 entries and 15 indexed attributes, using a 512 MB BDB cache… The resulting id2entry database is about 800 MB; with all indexing the total size is around 2.1 GB.

The syntax for indexing is:

	index [attributes] [index type]

Multiple attributes and index types are comma-delimited. These are the most useful index types:

pres

Match on the attribute type, rather than the value of the attribute. For example, search for attributes like (objectclass=inetOrgPerson) or (attribute=mail).

eq

Match the exact attribute value, like (cn=fred) returns only exact "fred" matches.

sub

Indexes for wildcard searches, like (cn=lisa*). There are several variations on sub. For example, subinitial is optimized for (cn=lisa*)-type searches, subfinal is optimized for (cn=*smith)-type searches, and subany is optimized for (cn=*isa*).

Creating unnecessary indexes will hurt performance. Unindexed searches will always succeed; your goal is to index the most common searches, and not worry about infrequent search types. Smart indexing will boost performance noticeably. Watch your logfiles to see what your users or applications are looking for; that's your best guide to deciding what to index. See Recipe 12.12 for more information.

See Also