Issue 7830 - MDB Size grown a lot during massive updates and concurrent read access
Summary: MDB Size grown a lot during massive updates and concurrent read access
Status: VERIFIED DUPLICATE of issue 7974
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.39
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-28 08:28 UTC by antonin.meunier@cgi.com
Modified: 2020-03-20 18:44 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description antonin.meunier@cgi.com 2014-03-28 08:28:37 UTC
Full_Name: Antonin Meunier
Version: 2.4.39
OS: Red Hat 6.5
URL: 
Submission from: (NULL) (195.6.127.108)


Ldap is set to a maximum MDB database size of 80GB.
Ldap uses 20GB of effective Size.
There are approximately 60 index , 1500000 peoples and 4500000 groups.
The LDAP is accessed in read / write by about 20 tomcat.
In parallel to this, update treatment (inject ldif) are started performing lots
of massive upates (750 000, 500 000 groups).
When processing the massives updates, the MDB size increases to the 80max and
therefore the treatment plant updates.
If I stop all tomcat, the problem no longer occurs.
So it seems that the problem comes from locks that are placed on the pages of
indexes and data by readers and force to create new pages for changes with
conservation of all intermediate pages.
After that, the only way to find a "normal" size is to export the ldap , delete
it and re-import the backup.
The LDAP database is then again 20GB
Comment 1 Leonid Yuriev 2014-10-23 05:37:34 UTC
Seems to will be fixed by ITS#7974.


Comment 2 OpenLDAP project 2017-04-12 16:40:33 UTC
Duplicate ITS#7974?
Comment 3 Quanah Gibson-Mount 2017-04-12 16:40:33 UTC
changed notes
moved from Incoming to Software Bugs
Comment 4 Quanah Gibson-Mount 2020-03-20 18:44:14 UTC

*** This issue has been marked as a duplicate of issue 7974 ***