OpenLDAP’s new memory-mapped backend, mdb, is ready for production. It was first introducted over a year ago, and since then, the OpenLDAP developers (Howard Chu in particular) have put quite a bit of work into getting all of the bugs worked out.
The OpenLDAP mailing lists report that several companies are deploying it in production:
http://www.openldap.org/lists/openldap-technical/201208/msg00137.html
The latest version of email/collaboration software Zimbra uses the mdb backend as well:
http://wiki.zimbra.com/wiki/OpenLDAP_Tuning_Keys_8.0#OpenLDAP_Tuning_Keys
All of this leads me to believe it’s production-ready. I’ve been running it myself at my own job for a couple weeks now, and it’s actually lived up to the hype. It really is faster, uses less memory, and is way easier to configure. You can read more about the advantages of mdb here: coming soon: memory-mapped db for OpenLDAP
Here’s a short list of what I would consider the caveats:
- Since it’s new technology, I highly recommend compiling the latest version of OpenLDAP (as of this posting 2.4.33) to get the latest bug fixes and performance improvements. I have a page of useful tips for compiling OpenLDAP to get the most out of it here: compiling OpenLDAP.
- Write performance is still being optimized. My personal recommendation would be to continue to use hdb on the master server (properly optimized), and mdb on the replica servers.
I’m guessing because of the previous point, it can take quite a bit longer to do the initial database load. Using hdb it took a few hours to slapadd our database, but it’s taking around 12 hours to slapadd it using mdb. It’s worth the wait, though.
(see comments)
I’ve updated my wiki on optimizing OpenLDAP with instructions for mdb. Instead of worrying about locks and three different levels of caches, there’s just one important option which is trivial to configure:
More information about mdb is available here:
http://highlandsun.com/hyc/mdb/
Now, if Symas would only post some updated benchmarks, I could point to just how much faster OpenLDAP is than the competition…
A great set of benchmarks are in Howard’s presentation from LinuxCon 2012. A copy of the presentation can be found here: http://www.symas.com/documents/LinuxCon12-MDB.pdf. Also, it shouldn’t take 12 hours to load a database- either move the database file to an ext2 file system or turn off journaling. MDB doesn’t benefit from it anyway.
Yes, I just saw here yesterday that the slapadd slowness is probably due to the filesystem: http://www.openldap.org/lists/openldap-technical/201208/msg00238.html
but I haven’t had a chance to compare it to a slapadd using optimized hdb on the same system yet.
Regarding benchmarks, comparing to other database backends is nice, but what I’d like to see is comparison to other directory products (OpenDJ, 389/Red Hat Directory Server, Apache Directory Server, etc). The most recent benchmarks of that type are so old I have to use the Wayback Machine just to see them:
http://web.archive.org/web/20081024133432/http://www.connexitor.com/blog/pivot/entry.php?id=131
Thanks!
I went ahead and tested a slappadd using optimized hdb on the same machine, and mdb was definitely faster. It continues to impress!
I finally got around to running a slapadd using ext4 with journaling disabled and a few other tweaks (http://fenidik.blogspot.com/2010/03/ext4-disable-journal.html). slapadd took around 30 minutes, down from over 12 hours using a 1.6 GB LDIF!
b: The last slide shows slamd search results of OpenLDAP and also two other (unnamed) directory servers. The other two were actually OpenDJ and XXX (we are not allowed to name them), respectively. 389DS and ApacheDS wouldn’t even register on the graph. The deficit in their performance is so vast that it’s no longer even interesting to test those packages any more.