Description Stefan Gohmann 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.

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

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

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

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