> Vadim> Michael,
> Vadim> Thread-pool should be used very carefully.
>
> Vadim> We tested it and InnoDB hangs in sysbench benchmarks when count of
> Vadim> client connection > size of thread-pool.
>
> Yes, this a problem when you have more locks than threads.
> The innodb deadlock detector has to timeout the hanged items.
>
> Vadim> The problem is transaction state. Some connections may do internals
> Vadim> locks and after that could not enter to pool, because all slots are busy.
> Vadim> I expect you will have the same problem with Maria when it can fully
> Vadim> support transactions.
>
> That is one of the main reasons I added --extra-port to MariaDB
> This allows you to connect and check/kill things if you get a hang.
>
> So things are not perfect now, but at least a little better.
>
> In the future we have to also look at creating more pool-threads when
> all pool-threads gets locked by a handler.
>
This is a good solution IMO. You could base it on how long the next
queue item has been in the pool. So you determine a maximum latency
value that makes sense, and you grow the thread pool any time tasks are
waiting longer than that to execute, up to a certain number of threads
that would be your hard limit. Once you reach the hard limit, you
refuse to grow the pool further, and if no queries are being dequeued
after a long timeout, you could determine that things are deadlocked and
panic / start killing things, or let the user make that decision using
extra-port.
