Am 17.07.2017 um 17:11 schrieb Vladislav Vaintroub:
Our thread pool tries to keep the number of active (non-waiting)
threads the same as thread_pool_size. You can calculate "active count"
as (Threadpool_threads - Threadpool_idle_threads) in the "show
status" output.
If all queries run lightning fast / never block, active count would
be thread_pool_size, and Threadpool_idle_threads will be 0.
Yet, there are different situations where overall number of threads
grows, due to contention and/or long running queries. Often, also
active count grows somewhat, but we have a mechanism to handle this
"oversubscription", so it does not run out of control.
It is well possible that bumping active threads will increase the
throughput and decrease the query time in your benchmark. If you like
to experiment, the easiest way to do it is to increase
thread_pool_size. You may, dependent on the load, also get more
active threads by decreasing thread_pool_stall_limit and/or
increasing thread_pool_oversubscribe, but I would not recommend this,
as it is not really reliably way to achieve more active threads.
"thread_pool_oversubscribe" did not help to get the "Resource
temporarily unavailable" solved
As explained before, the situation with "benchmark end", where a lot
of threads are created, is probably due to lock contention in
concurrent disconnects
since only the connections between "ab" and httpd with mod_prefork are
keep-alive you have the same amount of disconnects through the whole
benchmark otherwise with persistent connections which have their own
drawback and are not a option the connection handling on the mariadb
side won#t be a problem at all
