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(a)mac.com
Sent from my browser.
On May 31, 2017, at 02:38 PM, Mark Reynolds <mareynol(a)redhat.com> 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(a)mac.com
Sent from my browser.
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Show replies by date