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:
>>>> 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?
>> 
> I read your bug report a while back, and made sure that slapi-nis was 
> disabled.
> 
> 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 
> environment?
> 
> 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?
> 
> Rich/Nalin,
> Was there a bug in managed entries that's been fixed in the current 389-ds 
> versions available in Red Hat / CentOS  6?
> 
> 
> Regards,
> Siggi
> 

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
objectClass: top
objectClass: extensibleObject
cn: monitor
database: ldbm database
readonly: 0
entrycachehits: 904077
entrycachetries: 923802
entrycachehitratio: 97
currententrycachesize: 79607895
maxentrycachesize: 104857600
currententrycachecount: 10301
maxentrycachecount: -1
dncachehits: 3
dncachetries: 10302
dncachehitratio: 0
currentdncachesize: 1861653
maxdncachesize: 10485760
currentdncachecount: 10301
maxdncachecount: -1



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to