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