since i am still searching for how to get the "connection handling is buggy (HY000/2002): Resource temporarily unavailable)" contention on the unix socket solved i found the "back_log" param recently https://jira.mariadb.org/browse/MDEV-13375 * it's completly ignored * it's on 110 and not at "max_connections" as the docs state DUNNO if that could improve the situation but it really makes me sad to see the "Resource temporarily unavailable" errors while a concurrency of 250 is really a joke on a 3.50 Ghz 4-core with 32 GB RAM when that also happens with just connect and do nothing else i also opened https://bugs.php.net/bug.php?id=74971 recently because that really limits scalability while the application still responds within 0.003 seconds to additional requests in the browser which also makes clear that timeouts should not happen at all Am 17.07.2017 um 17:36 schrieb Reindl Harald:
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