Issue 7455 - MDB database grows without bound
Summary: MDB database grows without bound
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.33
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-28 18:50 UTC by Quanah Gibson-Mount
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments
diff.txt (5.11 KB, text/plain)
2012-11-30 13:09 UTC, Howard Chu
Details

Note You need to log in before you can comment on or make changes to this issue.
Description Quanah Gibson-Mount 2012-11-28 18:50:06 UTC
Full_Name: Quanah Gibson-Mount
Version: 2.4.33
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.196.25.250)


I have a very small DB (about 25MB from a fresh slapadd).  However, the data.mdb
file grows by about 50MB a day.  I.e., the database size on disk *doubles* every
day.  It is now up to 571MB in size after 


Here is the DB after a fresh slapadd:
zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
25M     data.mdb

Here is the DB on the production server:
[zimbra@ldap01-zcs db]$ du -c -h data.mdb
571M    data.mdb
Comment 1 Quanah Gibson-Mount 2012-11-28 20:16:40 UTC
--On Wednesday, November 28, 2012 6:50 PM +0000 quanah@OpenLDAP.org wrote:

> Here is the DB after a fresh slapadd:
> zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
> 25M     data.mdb
>
> Here is the DB on the production server:
> [zimbra@ldap01-zcs db]$ du -c -h data.mdb
> 571M    data.mdb


In 1 week:

24,108 MODs
14 Adds
7 Deletes

For a client with a large database of several gigs, this will quickly lead 
to significant problems, even with a large amount of free disk space.  If I 
have a client with a 12GB DB, then they'll hit their DB maxsize of 80GB in 
just a few days.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Comment 2 Howard Chu 2012-11-28 21:13:13 UTC
quanah@OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.33
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.196.25.250)
>
>
> I have a very small DB (about 25MB from a fresh slapadd).  However, the data.mdb
> file grows by about 50MB a day.  I.e., the database size on disk *doubles* every
> day.  It is now up to 571MB in size after
>
>
> Here is the DB after a fresh slapadd:
> zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
> 25M     data.mdb
>
> Here is the DB on the production server:
> [zimbra@ldap01-zcs db]$ du -c -h data.mdb
> 571M    data.mdb

Based on the mdb_stat output you pasted, this is simply a case of overflow 
pages not reusing freelist pages. The significant info here is the freelist 
info and the number of overflow pages used in the id2e database.

   Environment Info
     Map address: (nil)
     Map size: 85899345920
     Page size: 4096
     Max pages: 20971520
     Number of pages used: 146230
     Last transaction ID: 192037
     Max readers: 126
     Number of readers used: 10
   Freelist Status
     Tree depth: 3
     Branch pages: 7
     Leaf pages: 668
     Overflow pages: 32
     Entries: 10671
     Free pages: 141005
   Status of Main DB
     Tree depth: 1
     Branch pages: 0
     Leaf pages: 1
     Overflow pages: 0
     Entries: 38
     ...
   Status of ad2i
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 20
     Overflow pages: 0
     Entries: 976
   Status of cn
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 231
     Overflow pages: 0
     Entries: 30224
   Status of displayName
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 91
     Overflow pages: 0
     Entries: 13625
   Status of dn2i
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 114
     Overflow pages: 0
     Entries: 5935
   Status of entryCSN
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 37
     Overflow pages: 0
     Entries: 2967
   Status of entryUUID
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 26
     Overflow pages: 0
     Entries: 2967
   Status of givenName
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 24
     Overflow pages: 0
     Entries: 3318
   Status of id2e
     Tree depth: 3
     Branch pages: 7
     Leaf pages: 721
     Overflow pages: 1937
     Entries: 2968
   Status of mail
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 141
     Overflow pages: 0
     Entries: 33250
   Status of objectClass
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 9
     Overflow pages: 0
     Entries: 9353
   Status of sn
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 53
     Overflow pages: 0
     Entries: 7502
   Status of uid
     Tree depth: 2
     Branch pages: 1
     Leaf pages: 13
     Overflow pages: 0
     Entries: 3148
     ...


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 3 Howard Chu 2012-11-30 01:06:48 UTC
changed state Open to Active
Comment 4 Howard Chu 2012-11-30 13:09:34 UTC
Howard Chu wrote:
> quanah@OpenLDAP.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.4.33
>> OS: Linux 2.6
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (74.196.25.250)
>>
>>
>> I have a very small DB (about 25MB from a fresh slapadd).  However, the data.mdb
>> file grows by about 50MB a day.  I.e., the database size on disk *doubles* every
>> day.  It is now up to 571MB in size after
>>
>>
>> Here is the DB after a fresh slapadd:
>> zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb
>> 25M     data.mdb
>>
>> Here is the DB on the production server:
>> [zimbra@ldap01-zcs db]$ du -c -h data.mdb
>> 571M    data.mdb
>
> Based on the mdb_stat output you pasted, this is simply a case of overflow
> pages not reusing freelist pages. The significant info here is the freelist
> info and the number of overflow pages used in the id2e database.

Here's the patch we're currently testing for this issue.
It appears to work but is maybe not being aggressive enough in reclaiming 
space. We may want to increase the number of retries a bit more.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
Comment 5 Howard Chu 2012-11-30 20:21:35 UTC
changed notes
changed state Active to Test
moved from Incoming to Software Bugs
Comment 6 Quanah Gibson-Mount 2012-11-30 22:31:14 UTC
changed notes
changed state Test to Release
Comment 7 Quanah Gibson-Mount 2012-12-13 17:23:22 UTC
changed notes
changed state Release to Open
Comment 8 Howard Chu 2013-01-09 16:36:56 UTC
changed notes
changed state Open to Test
Comment 9 Quanah Gibson-Mount 2013-01-09 20:31:27 UTC
changed notes
changed state Test to Release
Comment 10 Quanah Gibson-Mount 2013-02-08 22:00:46 UTC
changed notes
changed state Release to Open
Comment 11 Howard Chu 2013-02-15 13:36:09 UTC
changed notes
changed state Open to Test
Comment 12 Quanah Gibson-Mount 2013-02-26 20:17:32 UTC
changed notes
changed state Test to Release
Comment 13 Quanah Gibson-Mount 2013-03-05 02:19:52 UTC
changed notes
changed state Release to Closed
Comment 14 OpenLDAP project 2014-08-01 21:04:46 UTC
fixed in master
fixed in RE24