largish member changes causing problems

03-27-2012, 02:25 AM

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).

ds = 1.2.9.9
RHEL = 5.7

Thoughts?

/mrg
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 01:17 PM

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 01:50 PM

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.

/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@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 01:58 PM

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 02:01 PM

I just checked and only 1.2.10.3-1.el5 is in the epel-testing repo

/mrg

On Mar 27, 2012, at 9:50, Michael R. Gettes wrote:

>
> I judge from your questions this is not a known problem.
>
> /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?
>>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 02:03 PM

On 03/27/2012 08:01 AM, Michael R. Gettes wrote:

I just checked and only 1.2.10.3-1.el5 is in the epel-testing repo
1.2.10.3 should be fine as long as you don't use compare operations on
virtual attributes.
I just pushed 1.2.10.4 to epel-testing - it should show up in the
mirrors in a couple of days.

/mrg

On Mar 27, 2012, at 9:50, Michael R. Gettes wrote:

I judge from your questions this is not a known problem.

/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?

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 02:11 PM

Michael,

Something else to check is the Referential Integrity Plugin. Is it
enabled? If it is, something that I have seen that helps is to set the
interval from 0 to 1 second. Or turn it off to rule it out, but then of
course it won't do its job.

Regards,
Mark

On 03/26/2012 10: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).

ds = 1.2.9.9
RHEL = 5.7

Thoughts?

/mrg
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 04:28 PM

Ref int is not on.

On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol@redhat.com> wrote:
Michael,

Something else to check is the Referential Integrity Plugin. *Is it enabled? *If it is, something that I have seen that helps is to set the interval from 0 to 1 second. *Or turn it off to rule it out, but then of course it won't do its job.

Regards,

Mark

On 03/26/2012 10: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).

ds = 1.2.9.9

RHEL = 5.7

Thoughts?

/mrg

--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 05:39 PM

It may also be the memberOf plugin, is the attribute memberOf
replicated in your configuration? I tested deleting/adding/replacing
in one shot a group of ~6000 entries with memberOf and referint
enabled. It took about 30 seconds to complete but it never hanged
(389DS v1.2.9.10).

2012/3/27 Michael Gettes <gettes@gmail.com>:
> Ref int is not on.
>
> On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol@redhat.com> wrote:
>>
>> Michael,
>>
>> Something else to check is the Referential Integrity Plugin. *Is it
>> enabled? *If it is, something that I have seen that helps is to set the
>> interval from 0 to 1 second. *Or turn it off to rule it out, but then of
>> course it won't do its job.
>>
>> Regards,
>> Mark
>>
>> On 03/26/2012 10: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).
>>>
>>> ds = 1.2.9.9
>>> RHEL = 5.7
>>>
>>> Thoughts?
>>>
>>> /mrg
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

03-27-2012, 05:54 PM

Nope, no memberof either.

On Mar 27, 2012 1:39 PM, "Andrey Ivanov" <andrey.ivanov@polytechnique.fr> wrote:
It may also be the memberOf plugin, is the attribute memberOf

replicated in your configuration? I tested deleting/adding/replacing

in one shot a group of ~6000 entries with memberOf and referint

enabled. It took about 30 seconds to complete but it never hanged

(389DS v1.2.9.10).

2012/3/27 Michael Gettes <gettes@gmail.com>:

> Ref int is not on.

>

> On Mar 27, 2012 10:11 AM, "Mark Reynolds" <mareynol@redhat.com> wrote:

>>

>> Michael,

>>

>> Something else to check is the Referential Integrity Plugin. *Is it

>> enabled? *If it is, something that I have seen that helps is to set the

>> interval from 0 to 1 second. *Or turn it off to rule it out, but then of

>> course it won't do its job.

>>

>> Regards,

>> Mark

>>

>> On 03/26/2012 10: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).

>>>

>>> ds = 1.2.9.9

>>> RHEL = 5.7

>>>

>>> Thoughts?

>>>

>>> /mrg

>>> --

>>> 389 users mailing list

>>> 389-users@lists.fedoraproject.org

>>> https://admin.fedoraproject.org/mailman/listinfo/389-users

>

>

> --

> 389 users mailing list

> 389-users@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/389-users

--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users