3 ms·
I did not delve into the details as you might have, but whenever I see mmap associated with huge perf I tend to wonder about corruption. I've seen to many bench
by ldng 14y ago
I did not delve into the details as you might have, but whenever I see mmap associated with huge perf I tend to wonder about corruption. I've seen to many bench comparing ondisk stores with in mmap stores flushed to disk one in a while. Then you need extra steps/configs to get good enough reliability that hinder perf.
- snaky 14y ago>whenever I see mmap associated with huge perf I tend to wonder about corruption If that was the case with lmdb implementation, that works as OpenLDAP backend all over the world, most probably you would have heard about it from the news.
- ldng 14y agoYou've have a point. But then, it's a bench mark and it would not be the first time that a bench is done using different settings than in production. Like I said, that lmdb is used in OpenLDAP doesn't automatically mean it is used with the exact same configuration as in the benchmark ;-) Nor did I say a memory store is bad, it's just you're not comparing the same things. Redis could be added to the bench for instance.
- hyc_symas 14y agoIMO main-memory stores are bad, for multiple reasons. LMDB is not a main memory store, it is a fully ACID-compliant transactional store.
- jules 14y agoThat's certainly a possibility but I'll have to assume that they are running with the same durability guarantees unless proven otherwise :)
- hyc_symas 14y agoCorrect. In synchronous mode full ACID semantics are guaranteed. Writable mmap avoids memcpy()/write() overhead but msync() is still performed.