September 4, 2018 at 1:08 pm #23102jaimefgParticipant
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.
September 5, 2018 at 10:40 am #23124LudoModerator
- This topic was modified 5 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.October 10, 2018 at 10:38 am #23417jaimefgParticipant
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 youOctober 11, 2018 at 2:45 pm #23428LudoModerator
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.htmlOctober 11, 2018 at 9:42 pm #23436Michelle ReaginParticipant
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.
You must be logged in to reply to this topic.