[Date Prev][Date Next]
Re: Large Number of Transactions x Low performance
It's really like Andrew understood!
When I used the term group was to specify a node in the tree (objectclass type groupOfUniqueNames).
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:firstname.lastname@example.org] Em nome de Michael Ströder
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 to
> 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 really
> do need delta mode.
delta-syncrepl would only help if group membership is changed only for a few
members in one modify request.