On Jun 5, 2012, at 3:12 PM, Sigbjorn Lie wrote:
> On 06/05/2012 11:44 PM, JR Aquino wrote:
>> On Jun 5, 2012, at 1:54 PM, Sigbjorn Lie wrote:
>>> On 06/05/2012 10:42 PM, Steven Jones wrote:
>>>> 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?
>> 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
>> 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.
>> Are either of you currently utilizing sudo?
> I read your bug report a while back, and made sure that slapi-nis was
> I have tuned my cache size to 256MB. I believe that should be OK as my cache
> hit ratio sits at 97-99% ?
> I understand you have a farily large deployment, what cache size are you
> using? Are you using Fedora or Red Hat / CentOS as your production
> I do not use sudo with IPA yet, I am planning for doing that later. Is there
> any issues I should be aware of with sudo integration?
> Was there a bug in managed entries that's been fixed in the current 389-ds
> versions available in Red Hat / CentOS 6?
Ya it is true that I do have a large environment, but some of the hurdles that
I had to jump appeared to be ones that weren't related so much to the number of
hosts I had, but rather their amount of activity. I.e. automated single-sign
on scripts, people authenticating, general binds taking place all over...
I am using Fedora with FreeIPA 2.2 pending a migration to RHEL 6.3 and IPA 2.2
My measurements... ;)
dn: cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
database: ldbm database
Freeipa-users mailing list