It's really like Andrew understood!
When I used the term group was to specify a node in the tree (objectclass type
Group members are uniquemember attributes.
We have over 50000 uniquemembers in a single groupOfUniqueNames.
We have not set the sortvals, but I will provide. (When configured is necessary to make a
new load of data?)
As the management tool, it makes the inclusion or deletion of a single uniquemember
attribute at a time. But is not fast these operations thus need some tuning in OpenLDAP
and so I'm using you!
As for replication, I'm using delta, because as I read, and get it right, it only
replicates the operations on the attributes of the node, and not all its value as is done
in other types of replication. I like it to be faster.
De: openldap-technical [mailto:email@example.com] Em nome de Michael
Enviada em: sexta-feira, 30 de janeiro de 2015 09:48
Assunto: Re: Large Number of Transactions x Low performance
Andrew Findlay wrote:
> We have a tool (BMC Identity Management (formerly Control-SA))
Check how it modifies the groups.
First of all it's not clear to me whether the original poster really meant
If it rewrites the whole set of 'member' attributes each time
then you are
forcing the server to re-index every value.
Not only that it's horribly inefficient. With this approach you run into the
famous security issue back in those Windows 2000 days where removed group
members were accidently re-added because of concurrent write access.
The efficient way to do this is to specify the value that you want
remove or the one you want to add. It should be very quick.
Additionally LDAP PDUs manipulating many values at once grow very big.
Also look at your replication setup. With this sort of data you
do need delta mode.
delta-syncrepl would only help if group membership is changed only for a few
members in one modify request.