I think more work needs to be done on the MariaDB thread/connection pool. Does a worklog exist for that?

The problems are: * multi-core performance * stalled threads stall the pool

This is based on my review and testing of the feature in MySQL 6.0 and quickly browsing the code in MariaDB. I also fixed multi-core performance as a proof of concept but don't have access to that patch.

The multi-core performance problem occurs because only one event_base instance is used (see sql/scheduler.cc). Note that memcache uses one per CPU core. This is a big source of mutex contention. An additional problem is that EPOLLONESHOT is not used. I don't know if libevent supports that yet. Were it used one less interaction with libevent would be needed per query.

I reported the performance issue at http://bugs.mysql.com/bug.php?id=42288

An interesting decision when there are multiple event_base instances is whether the mapping between an event_base instance and connections is fixed. If it is fixed then there is less libevent work to do per-query and there will be less mutex contention. But if connections cannot migrate between event_base instances per query then there will be cases where too many pending queries wait for one and no pending queries exist for others.

I think that stalls are another problem to fix. When a user connection blocks on a row lock wait or another internal locks (and calls THD::enter_cond), then this is an opportunity to count this connection as not running and schedule another thread. This isn't a trivial problem to fix because it might require a new thread to be created. There is also the issue of what to do when another connection has been scheduled. In that case does the thread that just became runnable get to run immediately? If it was just granted a row lock or other lock then we want it to run right away. But that might cause X+1 threads to be running in the thread pool when the limit is X. The difference between X and X+1 is small. But this could lead to 2*X threads running. What is the limit?