Re: Performance Degradation with Split Database

[Paul Whitney <paul.whitney@xxxxxxx>]

Hi Mark,

Thanks for responding to my query.  I am in a somewhat constrained environment where posting any kind of log is not practical or permitted.

However, after much digging in the various tuning guides out there, I think I found the issue.  By default, the directory server is configured for a maximum of 30 concurrent threads (nsslapd-threadnumber).  While the tuning guide recommends threads should be set to 2 X CPU, I set it to 200.  This made all the difference in performance.  Drastically. We are still working on fine-tuning to improve groupRoot type queries response-times.

Not sure to what type of deployment the tuning guide is written to, but I think in an enterprise environment the numbers are too low. Perhaps it is based on a small lab/office environment and not an org with just under a million entries with non-static groups or users.  It would be nice if there were a table that provided numbers (customer-based survey) comparable to an organizations size/number of concurrent hits/etc.

Nevertheless, thank you!  This forum has definitely proven helpful in the past and look forward to future postings.

Regards,

Paul M. Whitney
E-mail: paul.whitney@xxxxxxx
Sent from my browser.

On May 31, 2017, at 02:38 PM, Mark Reynolds <mareynol@xxxxxxxxxx> wrote:

On 05/31/2017 02:36 PM, Paul Whitney wrote:

Still in migration mode from RHEL5/DS 8.2 to CentOS7/DS10 (389-ds-base 1.3.5.10-20).

Our one instance is setup with two databases (userRoot and groupRoot).  We are seeing some really high etimes when performing mods/search on the second database (groupRoot).  Wondering if anyone else has experienced this issue and what was done to overcome them?

Can you provide some access log snippets showing some searches & mods from start to finish with the high etimes?

Also, what kind of "mods" are you doing?

Thanks,
Mark

Server is vmware VM with 4 CPU, 64GB RAM, plenty of disk space. CentOS 7 is "tuned" for virtual-guest.

Paul M. Whitney
E-mail: paul.whitney@xxxxxxx
Sent from my browser.

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx