On 30/07/2019 15:42, Michael Ströder wrote:
On 7/30/19 11:20 AM, Ulrich Windl wrote:
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.
lmdb's memory and disk footprint is small. My Æ-DIR development VMs are really small (~200 MB RAM) and there are various web components running on the providers.
I even tested this stuff with Raspberry PI model 1. And it did not consume too much resources. (Of course SD cards have really slow disk I/O.)
AFAICS there is only one case where back-mdb is significantly slower than back-hdb: ITS#8875. But this is actively worked on.
*cough* I think you mean ITS#7657 ;-) It's good to see work being done on this issue and I can report that the performance is massively improved in the current 2.4.48 RC release compared to 2.4.47.
We actually managed to move away from using aliases due to this issue and another issue (this time on HDB) where the whole system ground to a halt when you went over 64K alias entries. (See my email to the list on 16th Nov 2015- I thought I'd submitted an ITS but I can't find it ao maybe I didn't)
So stop spreading FUD about lmdb. If you provide real-world evidence that back-mdb consumes more resources than back-hdb then present seriously worked out test results.
Ciao, Michael.
With the exception of the issue above I've found back-mdb to require less maintenance and be less prone to deadlocking under load and corruption than back-bdb/hdb. Having the database backend built-in and updated also means one less package dependency to worry about ;-)
RE: the community engagement time permitting I'd be happy to look over/ help out with the web documentation. One thing that might be useful is some form of "cookbook" with recipes for setting up some common OpenLDAP configs (e.g. single node, 2-way MMR, n-way MMR, single-master with multiple replicas etc).
Kind regards,
Mark