Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
LOL, that is ironic. Well we also discovered a significant boost by increasing the normalize DN cache limits from 20MB to 1GB. While 1GB may be overkill, without any real metric to compare against, we have the RAM to use and figure lets just give it a large cache. Our metrics improved dramatically again. Our average look ups are now mostly in the sub-second times.
Running pstack against the dirsrv PID provided us the tidbit to look further into the DN normalizing cache. (http://directory.fedoraproject.org/docs/389ds/design/normalized-dn-cache.html)
Paul M. Whitney E-mail: firstname.lastname@example.org Sent from my browser.
On Jun 04, 2017, at 09:25 PM, William Brown <email@example.com> wrote:
On Fri, 2017-06-02 at 19:14 +0000, Paul Whitney wrote: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 orgwith just under a million entries with non-static groups or users. Itwould be nice if there were a table that provided numbers(customer-based survey) comparable to an organizations size/number ofconcurrent hits/etc.
Funny you say this: Upcoming in 1.3.6 we released autotuning out of the
box. I've known for a long time tuning of threads and memory has been a
pain point for users and admins.
I rewrote out platform memory detection code to be accurate with regard
to hardware, rlimits and cgroups, and made autotuning the default. You
can read more here:
It also includes thread autotuning :) So there is no need for a table,
the server will scale up and down based on your hardware and limits
In the future we hope to add more improvements in the parallel
performance of threads in the server, so hopefully you should see
greater benefits in the future too from this type of change,
Hope that helps,
Red Hat, Australia/Brisbane