Quote Originally Posted by geoffc View Post
On 5/11/2019 5:18 PM, Marcus wrote:
> Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
>> On 5/10/2019 5:04 PM, Marcus wrote:
>>> My issue was resolved by MF. You can reference SR 101224048731.
>>> Basicly eDir did not have enough memory assigned and index was not set up
>>> correctly. Assigning more memory made a hugh difference for me, index made
>>> a bit more.

>> So was that hard cache limit on the DIB Cache? Or adding actual memory
>> to the server to use?

> Hi.
> The server had plenty of hardware, so it was changing the cache settings
> for eDirectory that was needed.

What sort of scale of change? I.e. Were you running with a hard coded
limit too low?

Aaron as I recall is of the opinion that on a Linux/Unix style OS low
DIB cache is fine, since file system caching will use the rest and
provide the same benefits. This seems counter, which is why I am curious
about the numbers before and after.

I guess there is alot in playing here, but this is the details for my case. Settings made to this environment are specific for this installation, so I guess you cannot and should not implement these settings, but rather use it as an input to solving other similar problems.

Server memory: 16 GB

DIB is 2 GB and we were running on a hard limit with 200 mb. The hard limit was then set to 4 GB.

In this environment we are allowing searches for Given Name, Surname and CN, so we disabled the default index and created a new with AncestorID (-a) included.
Add new index:
ndsindex add -h <server> -p <port> -a -D <ldap user dn> -W -s <server user dn> "gnSnCnAncID;Given Name\$Surname\$CN;value"

Disable default GivennameSurname index:
ndsindex suspend -h <server> -p <port> -D <ldap user dn> -W -s <server user dn> "GivennameSurname"

After these settings searches for users when assigning roles and resources went from about 5-10 seconds to >1 second.

Best regards