Slowness in mofication or deletion operations

This topic contains 4 replies, has 3 voices, and was last updated by  Michelle Reagin 8 months, 1 week ago.

  • Author
  • #23102

    Hi All. We are having some troubles with our OpenDJ installation. We have more than 2 million users organized into 3 groups of names. When we launch queries (ldapsearch) the response is very fast, but when we launch modification operations (add / remove members of a group of names) or delete (delete a user that belongs to one or more groups) these operations take a long time (between 15 and 25 seconds on average). I am not clear if it is a problem of resources, a configuration problem or a problem of any other type. Can you give me any indication to try to reduce the time these operations take? All operations are executed through the ldapmodify tool of OpenDJ using LDIF files that contain all the modifications or deletions to be made.

    Please, ask me for any information you need to help me. Thank you very much.

    • This topic was modified 9 months, 2 weeks ago by  Peter Major.

    Can you tell us the number of members in each group?
    And which version of OpenJD?

    There are possible optimisations that you want to try. One of them would be to enable an Entry Cache, with a filter to only cache those groups. That can help a little bit with reducing the I/Os needed to read the groups from disk.


    Hi Ludo, sorry for the delay in response. The largest group has more than 1.1M users, and the smallest has 150k. I’m interested in what you mention about the Entry Cache, but I’m not sure what it is. Could you give me a little more information or refer me to a section of the doc where it is explained? I do not know if you mean this or this other /3/configref/entry-cache.html

    Thank you


    With such large groups, you have to expect queries to be slow.
    A 1.1M user group represents at least 30MB to write to the disk.
    Adding a single member to the group requires that all 1.1M other values are checked against the new value to detect if it’s duplicated.
    And yes, I was meaning the Entry-Cache as documented in

     Michelle Reagin 

    If the entry cache doesn’t resolve your speed issues with entry creation, modification, and deletion, you could also look into moving away from static groups instead to dynamic group membership:

    Group membership would be managed based on an LDAP filter and adding members into the group would be as simple as modifying the user’s entry to match the LDAP filter, such as adding a specific value to an attribute. This would require evaluating the user’s group membership by looking at the isMemberOf value rather than querying the group for a list of member DNs.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

©2019 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?