Am 17.07.2017 um 15:37 schrieb Vladislav Vaintroub:
On 17.07.2017 15:07, Reindl Harald wrote:
see above, also another piece of my intial posting - why in the world does "Threadpool_threads" not reach the highest value under load but after the benchmark is finished
what makes me really worry here is while the load is running (mysqld each time restartet before start apache-benchmark)
+-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Threadpool_idle_threads | 181 | | Threadpool_threads | 189 | +-------------------------+-------+
after the benchmark has finished and the machine is idle: +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Threadpool_idle_threads | 207 | | Threadpool_threads | 208 | +-------------------------+-------+
The benchmarks are usually written in such a way, that all connections will disconnect *at the same time* at the end of benchmark.
The disconnect code runs through couple of into global locks (LOCK_thread_count, if I remember correctly, maybe some others), i.e if several connections disconnect at the same time, there will be contention.
What happens in case of the contention is that threadpool notices it , starts getting worried about all threads getting blocked and possibly deadlocked, and about not having enough spare threads to handle new requests. Thus threadpool will *increase* the number of threads in presence of contention.
If you wait long enough after the benchmark (long enough is longer that thread_pool_idle_timeout seconds), the excess threads will disappear
it's clear that they disappear after thread_pool_idle_timeout but on a benchmarks running for 120 seconds with 250 connections i expect that thread number also reache while the benchmark is actevily running