From: Jeremiah Gowdy
Date: March 18 2009 2:53pm
Subject: Re: [Maria-developers] Working on microsecond patches
List-Archive: http://lists.mysql.com/maria/459
Message-Id: <49C10AFD.9020601@basharteg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> 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.