maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Jeremiah" == Jeremiah Gowdy <basharteg@xxxxxxxxxxxxx> writes:

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.
>> 
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 
Jeremiah> extra-port.

Agree that this is a good way to do it.

I will copy the above to a worklog item;  Hope you don't mind....
http://askmonty.org/worklog/Server-RawIdeaBin/index.pl?tid=13

Regards,
Monty