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
