In the previous article, I introduced the working method of MySQL's connection management thread. In this article, I will introduce the second way of managing connections, the thread pool.
MySQL's default connection control method uses one thread for each connection to execute client requests. MySQL's thread pool is a server plug-in included in the Enterprise Edition. The purpose of using the thread pool is to improve the performance degradation caused by a large number of concurrent connections. Under the workload of a large number of concurrent connections, the use of thread pools can solve problems such as inability to use the CPU cache, excessive context switching overhead, and resource contention.
The thread pool function is composed of plug-in library files, server system variables, and detection points in the Performance Schema.
The thread pool is composed of a certain number of thread groups (the default is 16
configured through thread_pool_size ), each thread group manages a group of client connections, the maximum number of connections is 4096. After the connection is created, it will be allocated to the thread group in a polling manner. The connection pool breaks the one-to-one correspondence between each connection and thread. This is different from MySQL's default thread control method. The default method associates a thread with a connection so that a given thread executes all statements from its connection.
By default, the thread pool tries to ensure that at most one thread is executed at a time in each group, but sometimes for best performance, multiple threads are allowed to execute temporarily. There is a monitoring thread in each group, which is responsible for monitoring the connections assigned to the group. The thread will choose to execute the statement in the connection immediately or later. If the statement is the only one received and there is no currently queued or executing statement, the statement will be executed immediately. In other cases, it will be executed later. When the statement is judged to be executed immediately, the monitoring thread is responsible for executing the statement. If the execution can be completed quickly, the thread will return to the monitoring state. If the execution time of the statement is too long and stagnation occurs, the thread group will start a new monitoring thread. The thread pool plugin uses a background thread to monitor the state of the thread group to ensure that the thread group does not block the thread group due to stalled statements.
able to passthread_pool_stall_limitConfigure the length of the wait value. A short wait value allows the thread to start faster and also helps avoid deadlock situations. The long wait value is very useful for long-running workloads to avoid starting too many new statements while the current statement is executing.
bythread_pool_max_active_query_threadsSet the maximum number of threads to run. If the value is not 0, the value is the maximum number of threads allowed to run. Set it to 0 to use the default maximum value.
The thread pool focuses on limiting the number of concurrent running statements in a short time. It will prevent other statements from starting to execute before the execution statement reaches the waiting time. If the execution of the statement exceeds the waiting time, it is allowed to continue execution, but no other statements are prevented from starting. In this way, the thread pool tries to ensure that there will never be more than one short-running statement in each thread group, but there may be multiple long-running statements.
If you encounter disk I/O operations or user-level locks (row locks or table locks), the statement will be blocked and the thread group will be unusable. The callback function of the thread pool can ensure that the thread pool immediately starts a new thread in the group to execute another statement. When a blocked thread returns, the thread pool allows it to be restarted immediately.
The thread pool contains two queues, a high priority queue and a low priority queue. The currently executing statement and subsequent statements associated with the transaction will enter the high-priority queue, and other statements will enter the low-priority queue.
In addition, the thread pool reuses active threads to make better use of the CPU cache. This is an adjustment that has a great impact on performance.
Theoretically, the maximum number of threads that may appear is max_connectionsAnd thread_pool_size sum. This may happen when all connections are in execution mode, and each group has created an additional thread to monitor.
To sum up, MySQL's thread pool is designed to expand connections and avoid deadlocks. By grouping threads, prioritizing, and round-robin scheduling, the CPU cache is efficiently utilized, context switching overhead is reduced, and the performance of MySQL server is improved!