Learn LDAP - Performance Tuning

#Introduction

The directory now serves authentication, mail, web apps, and replication. At some point, a surge in traffic will make it slow. Episode 25 is about performance: tuning the mdb database itself, choosing indexes that match real queries, and raising the connection and operating system limits so the server doesn't run out of resources under load.

#mdb Database Tuning

The mdb backend is a memory-mapped key-value store — a database whose performance depends heavily on how much of it lives in memory and how much the file system must read. The core tuning values live in cn=config:

Parameter	What it does	Tuning rule
`olcDbMaxSize`	maximum database file size in bytes	must exceed expected growth; resizing is a downtime operation
`olcDbCacheSize`	number of page entries cached	larger = more memory, faster reads
`olcDbMaxReaders`	maximum concurrent readers	raise when you see reader exhaustion
`olcDbMaxIDL`	max index list length	limits how many index entries a single search may scan

olcDbMaxSize is the most common trap: the default is often 10 MB in packaged builds, and when data reaches it, writes fail. The 1 GB value (1073741824) is a reasonable production start — but make it proportional to the actual dataset, and plan for growth because changing it later requires stopping the server.

#Cache and Readers

Cache — mdb keeps recently-used pages in memory. A cache too small for the working set causes constant disk re-reads. Measure with cn=Monitor statistics (e.g. monitorDatabaseRead versus monitorDatabaseWrite) and raise olcDbCacheSize until the read pressure drops.
Readers — each active search takes a reader slot. If concurrent searches exceed olcDbMaxReaders, new searches fail with MDB_READERS_FULL. Raise the limit, but remember each reader consumes some memory; balance with the number of expected concurrent connections.
Writer — mdb allows only one writer at a time. Writes serialize; a batch of ldapadd of thousands of entries will queue. This is inherent to mdb — plan write bursts accordingly.

#Index Tuning

From episode 14, indexes are the biggest lever on search speed. The tuning version:

Index what is filtered, not what is returned — (uid=...) needs uid eq; returning mail as a result attribute does not need an index.
Add sub only where wildcards are used — (cn=*bang*) filters need sub; (uid=budi) does not. Unused sub indexes waste disk and write time.
Replication indexes — entryCSN eq and entryUUID eq keep syncrepl fast; an unindexed contextCSN lookup is a full scan on every sync.
Index bloat — with many sub/approx indexes, database growth outpaces data growth. Audit indexes every release cycle against real query patterns.

#Connection Limits

slapd has a set of limits to keep one client from starving the server:

size limits — maximum number of entries a single search returns.
time limits — maximum seconds a search may run.
olcSizeLimit/olcTimeLimit — global defaults applied when a limit isn't explicit.

plaintext

olcSizeLimit: 500
olcTimeLimit: 60

Assign generous limits to trusted DNs (admin, replication) and tight limits to anonymous and application binds. This prevents a single runaway query from blocking every other client.

#Operating System Tuning

The kernel and file system participate in performance too:

File descriptor limits — each LDAP connection consumes a descriptor; under heavy load, raise nofile for the slapd user.
Swap vs. memory — mdb maps the whole database file; the more that fits in RAM, the fewer page faults. Add RAM or shrink olcDbMaxSize if the working set spills to swap.
Storage media — SSD over HDD dramatically improves write latency; mdb's single writer amplifies slow-disk costs.
Network stack — check somaxconn for the accept queue under many simultaneous connections.
Filesystem — avoid filesystems with heavy journaling overhead for the database directory if writes dominate.

Checking descriptors and load

ulimit -n
systemctl show slapd -p LimitNOFILE

#Benchmarking

Tuning without measurement is guesswork. Measure before and after:

ldapsearch with time — a baseline for single queries.
ldapbench / benchrfc — simple throughput tools in the OpenLDAP source tree.
cn=Monitor — connection, operation, and database counters over time.
slapd-metrics / Prometheus — from episode 18, continuous dashboards show regression after a change.

Baseline search timing

time ldapsearch -x -D cn=admin,dc=example,dc=com -W \
  -b ou=people,dc=example,dc=com "(mail=*)"

Track three numbers on every change: search latency, throughput (ops/sec), and write latency. A tuning change that improves one while wrecking another is not an improvement.

Tip

Change one parameter at a time. If you raise olcDbCacheSize, cache and olcDbMaxReaders together, you won't know which one did the work — or which one caused a regression. Small, measured steps beat big blind jumps.

#Closing

In this episode 25 you tuned OpenLDAP performance: mdb parameters olcDbMaxSize, olcDbCacheSize, olcDbMaxReaders, and olcDbMaxIDL; cache and reader behavior including the single-writer model; index strategies based on real filters; olcLimits and global size/time limits; OS tuning for descriptors, RAM, and storage; and benchmarking with time, cn=Monitor, and Prometheus.

Key takeaways:

olcDbMaxSize is the first thing to check — running out is a write outage.
Cache hits beat speed — index and cache until reads come from memory.
Limits protect the whole system — trusted DNs get more, everyone else gets less.
Measure before you tune — one change at a time, with a baseline.

In the next episode, episode 26, we make the tuned system survive failures: HA & load balancing — mirror mode, HAProxy, Nginx, DNS load balancing, and failover patterns for the directory.