>>>>> "Jeremiah" == Jeremiah Gowdy <basharteg@stripped> writes:
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.
Jeremiah> This is a good solution IMO. You could base it on how long the next
Jeremiah> queue item has been in the pool. So you determine a maximum latency
Jeremiah> value that makes sense, and you grow the thread pool any time tasks are
Jeremiah> waiting longer than that to execute, up to a certain number of threads
Jeremiah> that would be your hard limit. Once you reach the hard limit, you
Jeremiah> refuse to grow the pool further, and if no queries are being dequeued
Jeremiah> after a long timeout, you could determine that things are deadlocked and
Jeremiah> panic / start killing things, or let the user make that decision using
Agree that this is a good way to do it.
I will copy the above to a worklog item; Hope you don't mind....