Hi,
I may have spoken too soon. I'm now using a 32MB toy database, typical for my
users. I'm pruning at 90% which seems to be about the right number, but… the
number of pages in my mdb_stat() isn't reducing. So I'll do a round of pruning,
maybe 5% of the records. But the next time I come
Jeremy Bernstein wrote:
Hi,
I may have spoken too soon. I'm now using a 32MB toy database, typical for
my users. I'm pruning at 90% which seems to be about the right number, but…
the number of pages in my mdb_stat() isn't reducing. So I'll do a round of
pruning, maybe 5% of the records. But
That makes sense, but I'm also seeing a similar problem with the freelist
entries. Once I start pruning (btw I'm not deleting in a single commit -- my
granularity is also 50 deletes per transaction, then I commit and reset the
cursor before continuing), the freepages freezes at a certain value
Hi OpenLDAP-Technical,
First post, thanks in advance for any assistance.
I am trying to manage database size for an application in which a fixed DB size
is necessary (user-specified and these users are ornery). My preferred strategy
is:
- write to the DB until it's (nearly?) full
- at that
Although I didn't figure out a good way to do what I want, this is what I am
now doing:
if (MDB_MAP_FULL while putting) {
abort txn, close the database
reopen the database @ larger mapsize
perform some pruning of dead records
commit txn, close the database
reopen the database @ old
Jeremy Bernstein wrote:
Although I didn't figure out a good way to do what I want, this is what I am
now doing:
if (MDB_MAP_FULL while putting) {
abort txn, close the database
reopen the database @ larger mapsize
perform some pruning of dead records
commit txn, close the database
Hi Howard,
Thanks for your response. I tried using mdb_stat() previously, but I wasn't
getting useful information. For instance, when testing a mini-DB (64K, 16 pages
I believe), I had something like 1 branch page, 2 leaf pages and 0 overflow
pages when I started getting MDB_MAP_FULL. My data
Thanks Howard,
OK, so I tried this again with a slightly more modest toy database (after
reading the presentation, thanks), 1MB (256 pages). Blasting a bunch of records
into it at once (with a transaction grain of 100 records) I am getting
MDB_MAP_FULL with 1 branch, 115 leaf and 0 overflow
Jeremy Bernstein wrote:
Thanks Howard,
OK, so I tried this again with a slightly more modest toy database (after
reading the presentation, thanks), 1MB (256 pages). Blasting a bunch of records
into it at once (with a transaction grain of 100 records) I am getting
MDB_MAP_FULL with 1 branch,
OK, that seems to be working. Thanks for the tip!
One thing that hung me up along the way: in my pruning, I am using a cursor to
iterate through the records and then mdb_cursor_del() to chop dead ones.
mdb_cursor_del() seems to set the cursor to the next record, so I'm actually
starting at the
10 matches
Mail list logo
