On Wed, Mar 18, 2009 at 7:23 AM, Michael Widenius <monty@stripped> wrote:
>>>>>> "Vadim" == Vadim Tkachenko <vadim@stripped> 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.
I want a method in handler.h to timeout/wakeup threads blocked in a
handler method. Many engines have the notion of blocking on a lock for
a row/page (Innodb, Maria, maybe Falcon and PBXT). The scheduler
cannot do anything to get those threads back today. I run Innodb with
a 50 second lock wait timeout. That is a very long time to wait when
all threads get tied up. The scheduler may be able to do this with
THD::enter_cond for things blocked above a storage engine and that may
require killing the current statement for the thread to be waked.
> In the future we have to also look at creating more pool-threads when
> all pool-threads gets locked by a handler.
I don't trust this unless the server is able to create one thread per
connection and when running a server with 10,000+ connections I don't
think that will be a wise thing to do. I think this approach will lead
to rare but spectacular failures for hung servers.
> Mailing list: https://launchpad.net/~maria-developers
> Post to : maria-developers@stripped
> Unsubscribe : https://launchpad.net/~maria-developers
> More help : https://help.launchpad.net/ListHelp