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
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
