Re: Performance Degradation with Split Database

[Paul Whitney <paul.whitney@xxxxxxx>]

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: paul.whitney@xxxxxxx
Sent from my browser.

On Jun 04, 2017, at 09:25 PM, William Brown <wibrown@xxxxxxxxxx> 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 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.

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:

http://www.port389.org/docs/389ds/design/autotuning.html

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
provided.

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,

--
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

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

Attachment: signature.asc
Description: PGP signature

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