[389-users] largish member changes causing problems

[Rich Megginson]

On 03/27/2012 07:50 AM, Michael R. Gettes wrote:
> I am using replication (2 masters, 3 consumers, fully replicated among them).  High CPU usage only on the master being modified.  It happens on either master when the operation is performed on it.  The MOD being made never actually completes - I have to kill -9 the server - so it never makes it to the other master or consumers by replication.  I should also note the changes I am making are in a single modify.  I figured you would ask about 1.2.10 - I have not yet gotten there - but I will try to make it happen this week.
>
> I judge from your questions this is not a known problem.
Dealing with large groups is problematic, but not known to completely 
clobber the server.
>
> /mrg
>
> On Mar 27, 2012, at 9:17, Rich Megginson wrote:
>
>> On 03/26/2012 08:25 PM, Michael R. Gettes wrote:
>>> I am a little perplexed.
>>>
>>> I am making a change to a groupOfNames object having some 16069 member attributes.  I am deleting nearly 16000 members and then adding nearly 16000 members.  CPU goes to 100% and never comes down.  I have plenty of memory allocated (700MB) to nss-slapd and I have made the adjustments to allow for large objects (maxbersize).  I end up having to kill -9 slapd.  the annoying thing is some times it works, some times it doesn't.  I can't seem to find any common conditions of the failures (or successes).
>> Are you using replication?  If so, do you see the high CPU usage on the master or on the replica?
>> Are you able to reproduce with 389-ds-base-1.2.10.4-1 in epel-testing?
>>> ds = 1.2.9.9
>>> RHEL = 5.7
>>>
>>> Thoughts?
>>>
>>> /mrg
>>> --
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users