3 ms·
The last issue is merely one of performance, not capability. I’ve successfully used LMDB in 32-bit land, though it takes some effort. I had to scan available
by jnwatson 8y ago
The last issue is merely one of performance, not capability.
I’ve successfully used LMDB in 32-bit land, though it takes some effort. I had to scan available virtual memory for the largest contiguous chunk and use that.
Bigger issues are growing the database size and performance in low memory. No transactions can be running to increase the map size, which is usually hard to coordinate.
Also, in low memory situations, LMDB’s performance suffers tremendously. It can be 100x slower, and commits can take seconds. You won’t run into it unless you are really hammering it, and the developer usually won’t notice because they usually have lots of RAM.
- hyc_symas 8y agore: 32bit land, You should look into MDB_VL32 in mdb.master as other posters have suggested. If any single commit takes multiple seconds, you've probably written too much data in a single transaction. Above about 512MB it starts preemptively flushing intermediate pages out, to keep the in-RAM footprint limited. Some of those intermediate pages will need to be read back in if your transactions are hitting all over the DB. This is where the main slowdown comes.
- hyc_symas 8y agoFwiw, we've benchmarked on Raspberry Pis with slow SDcards. You want to talk about low RAM situations and slow I/Os. The reality is still the same though - every other DB engine is many times slower under the same conditions. Even when the DB is 5x or 50x larger than RAM... http://www.lmdb.tech/bench/hyperdex/ http://www.lmdb.tech/bench/hyperdex/