You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/threadpool.md
+63-9Lines changed: 63 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,8 @@ The default method, called one-thread-per-connection, creates a new thread for e
8
8
9
9
MySQL supports thread pooling through the thread pool plugin, which replaces the default one-thread-per-connection model. When a statement arrives, the thread group either begins executing it immediately or queues it for later execution in a round-robin fashion. The high-priority queue consists of several thread groups, each managing client connections. Each thread group has a listener thread that listens for incoming statements from the connections assigned to the group. The thread pool exposes several system variables that can be used to configure its operation, such as thread_pool_size, thread_pool_algorithm, thread_pool_stall_limit, and others.
10
10
11
+
<imgsrc="../_static/thread-pool-diagram.png"alt="Thread pool diagram"width="250" />
12
+
11
13
The thread pool plugin consists of several thread groups, each of which manages a set of client connections. As connections are established, the thread pool assigns them to thread groups using the round-robin method. This method assigns threads fairly and efficiently. Here's how it works:
12
14
13
15
1. The thread pool starts with a set number of thread groups.
@@ -56,23 +58,75 @@ Starting with 8.0.14, Percona Server for MySQL uses the upstream implementation
56
58
57
59
Implemented in 8.0.12-1: We ported the `Thread Pool` feature from Percona Server for MySQL 5.7.
58
60
59
-
## Priority connection scheduling
60
61
61
-
The thread pool limits the number of concurrently running queries. The number of open transactions may remain high. Connections with already-started transactions are added to the end of the queue. A high number of open transactions has implications for the currently running queries. The [thread_pool_high_prio_tickets](#thread_pool_high_prio_tickets) variable controls the high-priority queue policy and assigns tickets to each new connection.
62
62
63
-
The thread pool adds the connection to the high-priority queue and decrements the ticket if the connection has the following attributes:
63
+
## Thread pool priority queues
64
+
65
+
The thread pool limits the number of concurrently running queries to improve
66
+
performance under high load. Even when concurrency is constrained, the number
67
+
of open transactions can remain high. The thread pool manages these connections
68
+
using priority queues.
69
+
70
+
When a new connection starts a transaction, the thread pool evaluates whether
71
+
to place it in the high-priority queue. It does so if both of the following
72
+
conditions are true:
73
+
74
+
- The connection has an open transaction.
75
+
- The connection has a non-zero number of high-priority tickets, as defined by
76
+
the `thread_pool_high_prio_tickets` variable.
77
+
78
+
Each time the thread pool schedules work, it checks the high-priority queue
79
+
first. If that queue is empty, it pulls from the low-priority queue. This
80
+
behavior ensures that transactions already in progress receive preferential
81
+
treatment.
82
+
83
+
If `thread_pool_high_prio_tickets` is set to `0`, all connections go to the
84
+
low-priority queue. If the value is greater than `0`, each new connection
85
+
receives that number of high-priority tickets. The thread pool decrements a
86
+
ticket each time it prioritizes a connection.
87
+
88
+
## Configuring `thread_pool_high_prio_mode`
89
+
90
+
The `thread_pool_high_prio_mode` variable controls how the thread pool assigns
91
+
priority to connections, and accepts the following values:
92
+
93
+
*`transactions`: Prioritizes statements that are part of an open transaction
94
+
(default).
95
+
96
+
*`statements`: Prioritizes all statements from a connection with available
97
+
high-priority tickets.
98
+
99
+
*`none`: Disables high-priority scheduling. All connections go to the
100
+
low-priority queue.
101
+
102
+
103
+
104
+
### Static configuration
105
+
106
+
To set the variable persistently, add the following to your `my.cnf` file:
107
+
108
+
```ini
109
+
[mysqld]
110
+
thread_pool_high_prio_mode = transactions
111
+
```
112
+
113
+
## Dynamic configuration
114
+
115
+
You can also change this setting at runtime without restarting:
116
+
117
+
```
118
+
mysql> SET GLOBAL thread_pool_high_prio_mode = 'transactions';
119
+
```
64
120
65
-
* Has an open transaction
121
+
This change takes effect immediately for new connections only. Existing client sessions continue to operate under the previously active mode. To ensure all clients reflect the new behavior, either:
66
122
67
-
*Has a non-zero number of high-priority tickets
123
+
*Restart the server, or
68
124
69
-
Otherwise, the variable adds the connection to the low-priority queue with the initial value.
125
+
* Have connected clients disconnect and reconnect manually.
70
126
71
-
Each time, the thread pool checks the high-priority queue for the next connection. When the high-priority queue is empty, the thread pool picks connections from the low-priority queue. The default behavior is to put events from already started transactions into the high-priority queue.
127
+
This dynamic adjustment enables fine-tuning thread scheduling behavior in production systems without downtime.
72
128
73
-
If the value equals `0`, all connections are put into the low-priority queue. If the value exceeds zero, each connection could be put into a high-priority queue.
74
129
75
-
The [thread_pool_high_prio_mode](#thread_pool_high_prio_mode) variable prioritizes all statements for a connection or assigns connections to the low-priority queue. To implement this new [thread_pool_high_prio_mode](#thread_pool_high_prio_mode) variable
0 commit comments