Hi!

...

...

...

...

"Jeremiah" == Jeremiah Gowdy <basharteg@basharteg.com> 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