Solving Slow Write Performance

Solving Slow Write Performance

Multivalued Attributes

The main culprit of slow write performance are entries with large numbers of multivalued attributes. The most common type of entry with large numbers of multivalued attributes is a group entry (groupOfNames, groupOfUniqueNames). Group entries often have hundreds or thousands of members. By default, groups store all members in a single blob. When a member of a group is added, modified or deleted, the entire entry must be rewritten. If a group is very large, rewriting the entry can take enormous amounts of time.

There are several settings that help resolve the issue:

multival/olcMultiVal

When multival/olcMultival is used, member attributes are written to a separate table in the database. This vastly improves write performance.

There are three elements to the multival/olcMultival setting:

1. An attribute list to designate what attributes multival/olcMultiVal should be applied to (or “default” for any attribute.)
2. A high threshold. If the number of attributes in the entry exceeds the high threshold, the attributes are split out to their own table.
3. A low threshold. If the number of attributes fall below the low threshold, the attributes will be joined back in the entry blob.

Example:

# slapd.conf
multival member uniqueMember 100 20

# cn=config
olcMultiVal: member uniqueMember 100 20

sortvals/olcSortVals

The sortvals/olcSortVals setting saves multivalued attributes in a sorted order. This improves not only write performance, but compare operations and search filters are processed more efficiently.

The sortvals/olcSortVals setting must be declared in the global section of the slapd configurations.

If using slapd.conf for configuration, sortvals should be set before any database declarations.

If using cn=config, olcSortVals must be set at the root level of the configuration database (cn=config).

Example:

# slapd.conf
sortvals member uniqueMember

# cn=config
olcSortVals: membert uniqueMember

LMDB Environment Flags

LMDB has an envflags/olcEnvFlags setting with several options for improved performance.

These settings should be used with caution, as they may make the database more susceptable to corruption.

nosync

Disables immediate synchronization of on-disk database contents with changes made in memory. If slapd or the operating system crashes, there is potential for data loss if there are changes that haven’t been written to disk.

nometasync

Flush the data on a commit, but skip the sync of the meta page. This mode is slightly faster than doing a full sync, but can potentially lose the last committed transaction if the operating system crashes. If both nometasync and nosync are set, the nosync flag takes precedence.

writemap

Uses a writable memory map instead of just read-only. This speeds up write operations but makes the database vulnerable to corruption in case any bugs in slapd cause stray writes into the mmap region.

mapasync

When using a writable memory map and performing flushes on each commit, use an asynchronous flush instead of a synchronous flush (the de‐fault). This option has no effect if writemap has not been set. It also has no effect if nosync is set.

Example:

# slapd.conf
envflags nosync

# cn=config
olcEnvFlags: nosync

Filesystem Issues

Write performance can be affected by the type of filesystem the database is stored on. LMDB databases do not perform well on journaled filesystems like XFS and Reiser4. In fact, journaling can make write performance worse.

Storing databases on non-journaled filesystems like Ext2 or Ext4 (with journaling disabled) are the preferred filesystems.

Disk Issues

The type of disk the database is stored on also affects write performance.

Locally attached storage is the preferred method. The best performing disk types are NVMe and SSD.

Networked file systems and SAN storage should be avoided.