----- Howard Chu hyc@symas.com wrote:
Brandon Hume wrote:
On 05/18/12 03:36 PM, Quanah Gibson-Mount wrote:
Are you using shm keys with BDB?
Not at this time.
I don't know anyone who is using BDB 5.3 at this point in time. I would back down to something less recent and see if you see the same issue. I've used BDB 4.7 for quite some time w/o issue.
Well, with 4.8.30, the problem is still evident. Overall, using delta-syncrepl seems to make a large difference. With my previous test (still with bdb 5.3) and delta-syncrepl, the slapd process grew to 16G before dying. With delta off (removing the 'syncdata=accesslog logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"' portion of the olcSyncrepl line) the node started and finished loading the entire DB and grew to about 5.7G in total.
The fact that switching off delta changes the behavior would point pretty squarely at a bug in the delta-sync consumer code, not anything in the underlying backend. If you can produce a small test case to demonstrate the problem, it would be a good idea to post this to the ITS.
Or it just means that the accesslog is receiving a significant number of changes and that the time configured for how often to delete the accesslog DB is too small. It will certainly grow without bound up to the time deletion kicks in. For some of our larger customers, I have delete run on all data older than 8 hours, every 2 hours, to keep the accesslog DB size down. I.e., there is still not necessarily evidence of a memory leak.
--Quanah