Bug 36725 - Increased IOPS with MDB backend
Increased IOPS with MDB backend
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0
Assigned To: Stefan Gohmann
Felix Botner
: interim-4
: 36713 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2014-11-15 11:56 CET by Stefan Gohmann
Modified: 2014-11-26 06:54 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2014-11-15 11:56:24 CET
In highly used test instances we saw that the IO operations with MDB are much higher than with BDB. Normally that is not a problem but if the machines run in environments with IO limits such as Amazon EC2 it could become a problem.

We should add some more variables to configure it and explain it in the performance guide:

I think we should add the envflags variable:

       envflags {nosync,nometasync,writemap,mapasync,nordahead}
              Specify flags for finer-grained control of the LMDB library's operation.

              nosync This is exactly the same as the dbnosync directive.

                     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.

                     Use 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.

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

                     Turn  off  file  readahead.  Usually  the OS performs readahead on every read request. This usually boosts read performance but can be harmful to random access read performance if the system's memory is full and the DB is larger than RAM. This
                     option is not implemented on Windows.

              Specify  that  on-disk  database  contents should not be immediately synchronized with in memory changes.  Enabling this option may improve performance at the expense of data security. In particular, if the operating system crashes before changes are
              flushed, some number of transactions may be lost.  By default, a full data flush/sync is performed when each transaction is committed.
Comment 1 Stefan Gohmann univentionstaff 2014-11-15 18:11:22 CET
I've added the UCR variable to univention-ldap: r55840

The values are described in the performance guide: r55845

Changelog: r55846

Jenkins definitions: r55847
Comment 2 Stefan Gohmann univentionstaff 2014-11-15 18:12:50 CET
*** Bug 36713 has been marked as a duplicate of this bug. ***
Comment 3 Felix Botner univentionstaff 2014-11-19 12:54:05 CET
(In reply to Stefan Gohmann from comment #1)
> I've added the UCR variable to univention-ldap: r55840


> The values are described in the performance guide: r55845


> Changelog: r55846


> Jenkins definitions: r55847

Comment 4 Stefan Gohmann univentionstaff 2014-11-26 06:54:53 CET
UCS 4.0-0 has been released:

If this error occurs again, please use "Clone This Bug".