Sunday, June 4, 2017

[389-users] Re: Performance Degradation with Split Database

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:

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,


William Brown
Software Engineer
Red Hat, Australia/Brisbane

No comments:

Post a Comment