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. > 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. 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. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
