[Freeipa-users] 389-ds memory usage

[JR Aquino]

On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:

> On 06/05/2012 10:42 PM, Steven Jones wrote:
>> Hi
>> 
>> This has bug has pretty much destroyed my IPA deployment.......I had a pretty bad memory leak had to reboot every 36 hours...made worse by trying later 6.3? rpms didnt fix the leak and it went split brain........2 months and no fix....boy did that open up a can of worms.....
>> 
>> :/
>> 
>> In my case I cant see how its churn as I have so few entries (<50) and Im adding no more items at present....unless a part of ipa is "replicating and diffing" in the background to check consistency?
>> 
>> I also have only one way replication now at most,  master to replica and no memory leak shows in Munin at present.........
>> 
>> but I seem to be faced with a rebuild from scratch.......
> 
> 
> Did you do the "max entry cache size" tuning? If you did, what did you set it to?
> 
> Did you do any other tuning from the 389-ds tuning guide?
> 
> 
> 
> Rgds,
> Siggi

When I had similar problems using Feodra (Not Redhat or CentOS) my underlying issues were: managed entries firing off any time an object was updated (every time someone successfully authenticates, kerberos updates the user object, which in turn would touch the mepmanaged entry for the user's private group)  Similar things happened when hostgroups were modified...

This was further complicated by inefficiencies in the way that slapi-nis was processing the compat pieces for the sudo rules and the netgroups (which are automatically create from every hostgroup)

Thus, when memberof fired off, slapi-nis recomputed a great deal of its chunk...

After getting those issues resolved, I tuned the max entry cache size.  But it took all the fixes to finally resolve the memory creep problem.

It is not at all clear to me whether or not the bug fixes for my problem have made it up into Redhat / CentOS though...  The slapi-nis versions definitely don't line up between fedora and redhat/centos...

Perhaps Nalin Or Rich can speak to some of that.

The bug itself was easiest to replicate with _big_ changes like deleting a group that had a great number of members for example, but the symptoms were similar for me were similar for day to date operation resulting in consumption that never freed.

https://bugzilla.redhat.com/show_bug.cgi?id=771493

Are either of you currently utilizing sudo?