Grouper Users - Open Discussion List

[Mark Cairney <>]

Hi,

I've found that using the sortVals setting on the member attribute
significantly reduces the impact of this, as does using the mdb backend
as opposed to bdb/hdb.

From the OpenLDAP docs:

olcSortVals: <attr> [...]
    Specify a list of multi-valued attributes whose values will always
be maintained in sorted order. Using this option will allow Modify,
Compare, and filter evaluations on these attributes to be performed more
efficiently. The resulting sort order depends on the attributes' syntax
and matching rules and may not correspond to lexical order or any other
recognizable order. This setting is only allowed in the frontend entry.

We're using this setting along with a couple of groups of >200K members
and although CPU spikes for about 5-10 seconds when these groups are
modified it hasn't as yet caused a service issue.

Kind regards,

Mark

On 30/01/17 16:19, Michael R Gettes wrote:
> None that I have from this quick interrogatory.
> 
> Sorry.
> 
> /mrg
> 
>> On Jan 30, 2017, at 11:00 AM, Jorj Bauer 
>> <>
>>  wrote:
>>
>> Thanks.
>>
>> Any data on whether or not specific OpenLDAP back-ends made significant 
>> differences?
>>
>> -- Jorj
>>
>> Sent from my iPhone
>>
>>> On Jan 30, 2017, at 10:50, Michael R Gettes 
>>> <>
>>>  wrote:
>>>
>>> I received only a few replies.  Others have run into this limitation of 
>>> openldap not being able to support large static group objects. The 
>>> problem is really large numbers of multi-valued attributes (not just 
>>> group objects).  My observation is 5 seconds to update when the group 
>>> object becomes greater than 35K-40K members.  Apparently, openldap has to 
>>> regenerate the member/uniquemember attributes for the entire object each 
>>> time.  This appears to be a known issue with openldap since at least 
>>> October of 2003.  People have switched to using 389/sun-oracle (the 
>>> iPlanet derivatives) or Active Directory.  There are probably other 
>>> directory servers able to support large group objects as well - but it 
>>> would appear openldap and derivates have this problem.
>>>
>>> i hope this helps.
>>>
>>> /mrg
>>>
>>>> On Jan 26, 2017, at 10:22 AM, Jorj Bauer 
>>>> <>
>>>>  wrote:
>>>>
>>>> I'd love to hear an anonymized roll-up of what you find. We're in early 
>>>> days of Grouper here and are picking a new LDAP back-end to replace our 
>>>> Oracle DSEE - perfect timing for us to find out what our future troubles 
>>>> are going to look like...
>>>>
>>>> -- Jorj
>>>>
>>>>
>>>>> On 01/26/2017 09:49 AM, Michael R Gettes wrote:
>>>>> Hi All,
>>>>>
>>>>> A few months ago there was discussion around large groups for grouper.  
>>>>> I believe someone from either UCLA or Oregon State (or maybe some place 
>>>>> else) indicated they had groups of 400K.  Would those people kindly 
>>>>> contact me off list?  I have a couple of questions for you - not about 
>>>>> grouper perf concerns, but about non-grouper perf concerns.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> /mrg
>>>>>
>>>
> 
> 

-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: 

PGP: 0x435A9621

*******************************/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Attachment: signature.asc
Description: OpenPGP digital signature