as you can see 96.7% of our store is taken up by these mapLN entries. we haven't found any documentation as to what these things are. this is killing one of our BDB stores because in the last 24 hours we've generated around 10,000 new .jdb files when we used to have a few hundred...
we're using je-3.3.74
we upgraded to je-3.3.74 (from 3.3.62) on November 3rd but this particular issue didn't show up until around 24 hours ago.
thanks for taking a look ~j
Edited by: jules | xoopit on Nov 13, 2008 11:59 AM
MapLNs are per-Database metadata, and they can become large because they contain the log cleaner's housekeeping information. For some reason, it looks like your actual (utilized) data in this environment has become small (you deleted almost everything?) but the obsolete MapLNs have not been cleaned yet.
Could you please run DbSpace as follows and send the output to my email address, mark.hayes at the obvious .com?
java -jar je.x.y.z.jar DbSpace -h <dir> -d
I am in and out right now, so I may not reply for a couple hours, but I will reply this afternoon or evening.
We've been working on this with the Xoopit folks and I wanted to follow up and post the resolution, since it potentially impacts everyone using JE 3.3.x.
There is a bug in JE 3.3.74 and earlier, in all versions of the 3.3.x product. The fix for this is in JE 3.3.75, which currently is available on request. We haven't decided when we'll update our download site with this updated release. If you would like the updated release, please send email to mark.hayes at the obvious .com (oracle).
Here's the change log entry for the bug, which should explain what you need to know:
Fix a bug that caused the space taken by internal metadata in JE log files to increase over a long period of time. The rate of increase was slow in most cases, but in at least one observed case became rapid after a long time period and after the log cleaner became backlogged. To determine whether your JE log exhibits this problem, run
java -jar je.x.y.z.jar DbPrintLog -h DIR -S
and examine the line labeled MapLN on the left. If the amount of the log taken by MapLNs is 10% or greater, or if you see this number increasing steadily over time, then your application is probably experiencing this problem.
By installing JE 3.3.75 or later, the excess disk space will automatically be reclaimed over time, as ordinary checkpoints and log cleaning occur. If you wish to recreate your database rather than wait for this to occur gradually, you can use DbDump and DbLoad to do so.
We'd like to express our appreciation and sincere thanks to Jules and the other folks at Xoopit who reported this problem and helped us to diagnose it. We would not have found or fixed this problem as quickly as we did without their help.
For reference, the support ticket # for this problem is: #16610
If you have further questions, please reply to this forum post.