[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: best practices WRT resizing a MDB backend?

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.


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)

"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.


  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/