MySQLThreadPool:ProblemDefinition

In this blog we will cover the problem that the thread pool is solving

and some high-level description of how it solves this problem.

In the traditional MySQL server model there is a one-to-one mapping between

thread and connection. Even the MySQL server has lots of code where thread

or some abbreviation of thread is actually representing a connection.

Obviously this mapping has served MySQL very well over the years, but there

are some cases where this model don't work so well.

One such case is where there are much more connections executing queries

simultaneously compared to the number of CPUs available in the server. The

MySQL Server also have scalability bottlenecks where performance suffers

when too many connections execute in parallel.

So effectively there are two reasons that can make performance suffer in

the original MySQL Server model.

The first is that many connections executing in parallel means that the

amount of data that the CPUs work on increases. This will decrease the

CPU cache hit rates. Lowering the CPU cache hit rate can have a significant

negative impact on server performance. Actually in some cases the amount

of memory allocated by the connections executing in parallel could at times

even supersede the memory available in the server. In this case we enter a

state called swapping which is very detrimental to performance.

The second problem is that the number of parallel queries and transactions

can have a negative impact on the throughput through the "critical sections"

of the MySQL Server (critical section is where mutexes are applied to

ensure only one CPU changes a certain data structure at a time, when such

a critical section becomes a scalability problem we call it a hot spot).

Statements that writes are more affected since they use more critical

sections.

Neither of those problems can be solved in the operating system scheduler.

However there are some operating systems that have attempted solving this

problem for generic applications on a higher level in the operating system.

Both of those problems have the impact that performance suffers more and

more as the number of statements executed in parallel increases.

In addition there are hot spots where the mutex is held for a longer time

when many concurrent statements and/or transactions are executed in

parallel. One such example is the transaction list in InnoDB where each

transaction is listed in a linked list. Thus when the number of concurrent

transactions increases the time to scan the list increases and the time

holding the lock increases and thus the hot spot becomes even hotter

as the concurrency increases.

Current solutions to these issues exist in InnoDB through use of the

configuration parameter --innodb-thread-concurrency. When this parameter

is set to a nonzero value, this indicates how many threads are

able to run through InnoDB code concurrently. This solution have its

use cases where it works well. It does however have the drawback that

the solution itself contains a hot spot that limits the MySQL server

scalability. It does also not contain any solution to limiting the

number of concurrent transactions.

In a previous alpha version of the MySQL Server (MySQL 6.0) a thread

pool was developed. This thread pool solved the problem with limiting

the number of concurrent threads executing. It did nothing to solve

the problem with limiting the number of concurrent transactions.

It was also a scalability bottleneck in itself. Finally it didn't

solve all issues regarding long queries and blocked queries.

This made it possible for the MySQL Server to become completely

blocked.

When developing the thread pool extension now available in the MySQL

Enterprise Edition we decided to start from a clean plate with the

following requirements:

1) Limit the number of concurrently executing statements to ensure

that each statement execution has sufficient CPU and memory resources

to fulfill its task.

2) Split threads and connection into thread groups that are

independently managed. This is to ensure that the thread pool

plugin itself doesn't become a scalability bottleneck. The

aim is that each thread group has one or zero active threads

at any point in time.

3) Limit the number of concurrently executing transactions

through prioritizing queued connections dependent on if

they have started a transaction or not.

4) Avoid deadlocks when a statement execution becomes long or

when the statement is blocked for some reason for an extended

time.

If you are interested in knowing more details of how the new

thread pool solves these requirements there will be a

webinar on Thursday 20 Oct 2011 at 9.00 PDT. Check here

for details on how to access it.

If you want to try out the thread pool go here.

参考：

http://mikaelronstrom.blogspot.ae/2011/10/mysql-thread-pool-problem-definition.html