FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 03-27-2012, 02:25 AM
"Michael R. Gettes"
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 01:17 PM
Rich Megginson
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 01:50 PM
"Michael R. Gettes"
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 01:58 PM
Rich Megginson
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 02:01 PM
"Michael R. Gettes"
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 02:03 PM
Rich Megginson
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 02:11 PM
Mark Reynolds
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 04:28 PM
Michael Gettes
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 05:39 PM
Andrey Ivanov
 
Default largish member changes causing problems

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
 
Old 03-27-2012, 05:54 PM
Michael Gettes
 
Default largish member changes causing problems

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
 

Thread Tools




All times are GMT. The time now is 06:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org