[
https://issues.apache.org/jira/browse/DIRSERVER-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu updated DIRSERVER-1459:
-------------------------------------
Fix Version/s: (was: 2.0.0-RC1)
1.5.6
Creating new release 1.5.6 just so we can get critical bugs like this one out.
Shooting for January 31st depending on the bug parade.
<OT>
Very nice issue filing btw. I like the description and the code. Would be
nice if everyone could submit issues like this. Hence why I want to react
rapidly to get you a fix.
</OT>
Just to let others know what I am thinking is causing this is a low level bug
in JdbmTable where the secondary BTree used for the values of duplicate key
table entries is not being deleted. So a modify is deleting the key and
orphaning the 2ndary table whose data stays in the jdbm file as a separate
tree. It is not being properly cleaned up on LDAP entry modify operations and
is especially impacting the master.db file. Would produce huge uniqueMember.db
files if we indexed this attribute as well.
The growth would look polynomia based on this hypothesis. I will update this
issue to show which tests are being used after getting it into the repository.
> Adding members to a groupOfNames results in polynomial increase in JDBM
> partition size
> --------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1459
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1459
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.5
> Environment: Any (tested on Linux and Mac OS X)
> Reporter: Ben Hoyt
> Assignee: Alex Karasulu
> Priority: Blocker
> Fix For: 1.5.6
>
> Attachments: DIRSERVER-1459.tar.gz, screenshot-1.jpg
>
>
> I noticed a polynomial increase JDBM partition size and therefore disk usage
> when adding users to groups in my ApacheDS instance. The vast majority of
> the usage (95+% once you hit a couple thousand users) is in
> workingDirectory/partitionId/master.db
> Further testing showed that simply adding a user is linear, as one would
> expect, and as 'apacheds-tools capacity' confirms. It is only when a user is
> made a member of a group that the JDBM partition size shoots up.
> Example statistics:
> Add 16,000 users - JDBM partition size = ~70 megabytes
> Now add those same 16,000 users to a single group (all in the same group) -
> JDBM partition size = ~19 GIGABYTES
> I'll work to attach a test case and some more numbers from my tests
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
