Feature Overview

In MySQL OLTP applications, the system schedules MySQL threads on the CPUs running the OS by default in the case of high concurrency, as shown in the left part in Figure 1. As a result, cross-NUMA access happens frequently, which increases CPU overheads and restricts the performance. Therefore, thread scheduling needs to be tuned to reduce the overhead of cross-NUMA access and improve system performance, as shown in the right part in Figure 1.

The MySQL NUMA scheduling tuning feature implements fine-grained scheduling of MySQL foreground and background threads. This feature improves the processing efficiency of key threads and reduces remote memory access to improve system performance. For details, see Figure 2.

• Background thread: This feature involves seven types of background threads that affect the system performance. The threads are related to the redo log and purge logic. The number of background threads is fixed. Each type of thread has only one thread instance and is started when the MySQL instance is started. You can specify a type of threads to run only on specified CPU cores. Proper parameter settings can isolate the CPU cores of different threads from each other so that the CPU cores can be fully scheduled, preventing from system bottlenecks.
• Foreground thread: MySQL assigns one thread for each client connection, so the number of foreground threads increases with the number of sessions. Similar to background thread scheduling, you can specify foreground threads to run on specified CPU cores. In addition, CPU cores can be grouped based on the NUMA information. In the lifecycle of the current session, foreground threads are migrated only on the CPU cores in the same group, but not across NUMA nodes, exploiting spatial locality in data access. To implement load balancing between groups, new foreground threads are scheduled to the group with fewer sessions.