Brian Reichert wrote:
On Thu, Aug 21, 2014 at 03:28:42PM -0700, Howard Chu wrote:
maxsize is the back-mdb keyword. mapsize is the LMDB API property. They both refer to the same thing. We used the word "maxsize" for back-mdb to impress upon sysadmins that this really is a long-term maximum, and not a setting that should be tuned on an ongoing basis.
Ok, that explains the terminology.
Can 'maxsize' ever be reduced after the fact? If so, is their guidance as to how much it can change (perhaps based on mdb_stat)?
Read the LMDB documentation.
What, this: http://symas.com/mdb/doc/ ?
A search for 'maxsize' or 'mapsize' yeilds no hits.
Seriously? http://symas.com/mdb/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5
The mdb_stats manpage tells me how to invoke it, but not how to interpret the results. I have seen other messages to this mailing list provide some guidance, but nothing that seemed to directly apply to my questions. Perhaps I'm missing some keyword somewhere.
My naive use of the LDMB backend has me assume the worst case, and now everyone is equally punished for having a 'big' (albeit sparse) database.
"Punished"? There is no penalty for configuring a large maxsize, no matter how small the actual data.
The 'punishment' is multifold:
- consumption of diskspace for storage (our database is stored on the same partition as our backups; perhaps not the best of plans).
Nonsense. It is a sparse file and doesn't consume any more space than is actually being used.
- the time it takes to compress/uncompress a backup.
Nonsense. Use mdb_copy to take the backup.
- the network bandwidth cost of transmitting a file that's larger than it needs to be.
Nonsense.