Slowness in mofication or deletion operations

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

  • Author
    Posts
  • #23102
     jaimefg 
    Participant

    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 1 month, 2 weeks ago by  Peter Major.
    #23124
     Ludo 
    Moderator

    Hi,
    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.

    #23417
     jaimefg 
    Participant

    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 https://backstage.forgerock.com/docs/opendj/2.6/configref/file-system-entry-cache.html or this other https://backstage.forgerock.com/docs/opendj /3/configref/entry-cache.html

    Thank you

    #23428
     Ludo 
    Moderator

    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 https://backstage.forgerock.com/docs/opendj/3/configref/fifo-entry-cache.html

    #23436
     Michelle Reagin 
    Participant

    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: https://backstage.forgerock.com/docs/opendj/3/server-dev-guide/#dynamic-groups

    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.

©2018 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?