maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

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