Quanah Gibson-Mount quanah@symas.com schrieb am 29.07.2019 um 17:02 in
Nachricht <4DD781BA4B249F2380158513@[192.168.1.39]>:
‑‑On Monday, July 29, 2019 9:51 AM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
[...]
There is no good reason to keep support for back‑bdb or back‑hdb at this point, regardless of the license change. They simply do not offer the read
or write performance that back‑lmdb offers, and they require significant and extensive tuning to even be remotely usable in even a medium scale deployment of few 100k entries. However, the fact that the license did change over 6 years ago has only hastened the inevitable.
Our LDAP server runs on a virtual machine together with an Apache web-server that generates a lot of graphics on the fly. The VM has about 700 MB RAM, the LDAP server has about 20000 entries, two databases and a dozen of indexes. The databases need 163MB on disk for the hdb database. The LDIF database dump has 153kB for config and 11MB for data, and the database is older than 6 years. So I think BDB/HDB are rather space-efficient.
I doubt that a busy LMDB will be happy which that little disk space after six years of changes. That's my major point against LMDB. I'm not saying that LMDB has no customers that really need it, but to be it seems a bit like overkill.
Apache eats about 150 MB virtual mem (5 MB resident), slapd 1.3GB virtual mem (77MB resident). I'm afraid LMDB will "eat up" much more RAM.
Don't get me wrong: We can make it big (CPUs, RAM, Disks, energy consumption ,cooling requirement), but isn't "making it small" more of an art? Today's software mostly isn't "using a lot of memory" but rather "wasting a lot of memory" IMHO.
Regards, Ulrich "What can we do to save the earth?"