On Feb 23, 2014, at 16.37, Nat! <[email protected]> wrote: > I wanted to resurrect this thread: >>> >>> Hi, >>> >>> I understand that the DB size has an upper limit set by the call to >>> mdb_env_set_mapsize . I wonder what is the best strategy for growing the >>> size. >>> >> The best strategy is to initially pick a large enough size that growing it >> is never an issue. E.g., set it to the amount of free space on the disk >> partition where the DB resides. As the docs state, when the DB is actually >> in use, there's no guarantee that there will be enough free system resources >> left for a resize attempt to even succeed. I.e., if you initially choose a >> small size, by the time you need to deal with it it may be too late. >> > I have a problem with the "best strategy" because at least on OS X, the > reserved file size of "data.mdb" is just the amount set by > mdb_env_set_mapsize. Clearly reserving the amount of free space in my user > partition would not be desirable, especially if I want to run more than just > one lmdb based program. > > So I tried to grow my db progressively, by setting mdb_env_set_mapsize first > to a small value and the enlarging it. Unfortunately it seems, that whenever > I increase the env_mapsize, all the committed data is lost and I start with a > clean database (determined by mdb_stat). > > So what gives ? The only thing I have come up with is, that I would need to > copy the old database(s) into the new one with a cursor, but that sounds lame.
generally speaking, i’d discourage you from looking at that limit from the perspective of “how large will my data be?”. instead, consider it a safeguard, for the os/environment. evaluate your particular environment, and use values amongst your various instances such that, were something unexpected to happen, the entire disk/partition/etc is not consumed to the point of choking out the os [or perhaps other more important processes, etc]. -ben
