Re: Antw: Re: OpenLDAP 2.5 plans and community engagement
>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
29.07.2019 um 17:02 in
Nachricht <4DD781BA4B249F2380158513(a)[192.168.1.39]>:
‑‑On Monday, July 29, 2019 9:51 AM +0200 Ulrich Windl
<Ulrich.Windl(a)rz.xn--uniregensburg-dm6g.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?"