Comments on: Index lock and adaptive search – next two biggest InnoDB problems

By: sky000

sky000 — Thu, 04 Mar 2010 05:18:47 +0000

Not only both read and write query using same secondary index will happen this problem,but also just only read query too.

like this:

http://bugs.mysql.com/bug.php?id=51543

By: peter

peter — Wed, 03 Mar 2010 22:13:28 +0000

Vadim,

Is it Mutex which protecting Index lock or is it RWLOCK ? I see no reason why readers should block other readers in either of them ?

By: Vadim

Vadim — Mon, 01 Mar 2010 18:35:39 +0000

artemg,

We did not test this setup yet.
Actually Gallera replication looks prefferable for me in this regard,
but I need yet to understand whan kind of latency we can have on simple transactions on
single box.

By: Vadim

Vadim — Mon, 01 Mar 2010 16:46:31 +0000

Tobias,

InnoDB has too many internal global structures which are blocked by single writer.
To add to alredy named index->lock and adaptive_search lock, there is single rollback segment and single lock on intrenal data dictionary.
It is not as bad as for MyISAM table level lock, but named issues do not allow to scale on multi-cpu/cores systems.

By: artemg

artemg — Mon, 01 Mar 2010 08:21:31 +0000

have you already tried/tested to bind several mysql instances to different cores/sockets on the same box and run them in master->slave configuration?
does it scale good enough, or there are other replicataion-specific bottlnecks?

By: Shlomi Noach

Shlomi Noach — Sun, 28 Feb 2010 13:16:20 +0000

With regard to index->mutex problem:
Another possible solution would be to manage overflow pages to the index. So that not all writes to the index are immediately affected in the B-Tree, but rather written — sequentially — to index-overflow-pages, which are later applied in batch jobs.
Index lookups will need to iterate both these structures.

By: Vadim

Vadim — Sun, 28 Feb 2010 05:37:58 +0000

Baron,

You are right, after fixing one bottleneck we will face another, and it will continue as long we have shread global structures.

So.. the solution to run 128 mysql instances on 128 cores does not look that bad

By: Baron Schwartz

Baron Schwartz — Sun, 28 Feb 2010 03:18:35 +0000

Vadim, the adaptive hash index is sometimes even the leading problem on standard non-plugin InnoDB in MySQL 5.0.x. I just saw a case of that today, on a server with 24 cores.

It seems to me that the global structures are inevitably going to become a global problem inside InnoDB. Adaptive hash index is one, but I think the insert buffer, undo logs, and probably almost everything else in the global tablespace is another. As I look into our crystal ball, I see us going from bottleneck to bottleneck Will we eventually end up with a storage engine that has nothing shared? Everything per-table or per-index?

By: Tobias Petry

Tobias Petry — Fri, 26 Feb 2010 11:52:22 +0000

Your explanation of the lock mutex sounds like the MyIsam implementation: Block all reads when there’s some data manipulation. But this can’t be true or? This would be as worse as MyIsam and would not fit into the concept of row-level-locking.