On 11/06/2016 04:07 PM, William Brown wrote:
On Fri, 2016-11-04 at 12:07 +0100, Ludwig Krispenz wrote:
On 11/04/2016 06:51 AM, William Brown wrote:
http://www.port389.org/docs/389ds/design/autotuning.html
I would like to hear discussion on this topic.
thread number:
independent of number of cpus I would have a default minmum number of
threads,
What do you think would be a good minimum? With too many threads to CPU,
we can cause an overhead in context switching that is not efficient.
Even if the threads are unused, or mostly idle?
your test result for reduced thread number is with clients quickly
handling responses and short operations.
But if some threads are serving lazy clients or do database access and
have to wait, you can quickly run out of threads handling new ops
Mmm this is true. Nunc-Stans helps a bit here, but not completely.
In this case, where there are a lot of mostly idle clients that want to
maintain an open connection, nunc-stans helps a great deal, both because
epoll is much better than a giant poll() array, and because libevent
maintains a sorted idle connection list for you.
I wonder if something like 16 or 24 or something is a good "minimum",
and then if we detect more then we start to scale up.
entry cache:
you should not only take the available memory into account but also the
size of the database, it doesn't make sense to blow up the cache and its
associated data (eg hashtables) for a small database just because the
memory is there
Well, the cache size is "how much we *could* use" not "how much we will
use". So setting a cache size of 20GB for a 10Mb database doesn't
matter, as we'll still only use ~10Mb of memory.
The inverse of this, is that if we did set cachesize on database size,
what happens with a large online bulkload? We would need to retune the
database cache size, which means a restart of the application. Not
something that IPA/Admins want to hear. I think it's safer to just have
the higher number.
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
