CPU Pinning (Optional)

CPU pinning (also called CPU affinity) is the practice of binding MaxScale threads to specific CPU cores. By default, the operating system scheduler moves threads between cores to balance load. While this is generally efficient, in high-concurrency workloads, context switching and cache invalidation can reduce performance and increase latency.

Why Use CPU Pinning

  1. Reduce Thread Migration Overhead
    Threads pinned to specific cores avoid moving between cores, reducing context switching and improving CPU cache utilization.
  2. Improve Cache Locality
    CPU caches (L1/L2/L3) maintain thread-local data. Pinning threads keeps data in the same core’s cache, improving query processing speed.
  3. Predictable Performance Under Load
    High-concurrency spikes can trigger uneven scheduling. Pinning ensures each MaxScale thread consistently handles its portion of client connections.
  4. Better Performance Monitoring
    When threads are pinned, CPU usage and thread-level metrics are more predictable, making tuning and diagnostics easier.

How to Enable CPU Pinning for MaxScale

MaxScale does not provide a native configuration option to pin threads. CPU pinning must be done at the operating system level.

Linux Example Using taskset

Bash
# Pin MaxScale process to CPUs 0-7
taskset -c 0-7 /usr/bin/maxscale -f /etc/maxscale.cnf

Systemd Service Example

Bash
[Service]
ExecStart=/usr/bin/maxscale -f /etc/maxscale.cnf
CPUAffinity=0 1 2 3 4 5 6 7

Notes:

  • The threads= parameter in the [maxscale] section still controls the number of MaxScale worker threads (typically equal to CPU cores).
  • CPU pinning applies at the process level, ensuring all MaxScale threads are constrained to the specified cores.
  • Always monitor CPU usage and performance metrics to verify benefits.

Summary:
CPU pinning is an optional optimization for high-concurrency MaxScale deployments. It improves cache locality, reduces thread migration, and provides more predictable performance, but it must be implemented via the OS, not within MaxScale configuration.

Considerations and Caveats

  • Over-pinning: Pinning more threads than CPU cores can reduce performance due to oversubscription.
  • Dynamic Workload: CPU pinning is less beneficial if your system runs many other processes competing for CPU.
  • Testing Required: Always benchmark with and without pinning to validate improvements.

Bottom line: CPU pinning is optional, but for high-concurrency, low-latency systems, it can improve throughput, reduce latency variance, and make performance more predictable.

Kester Riley

Kester Riley

Kester Riley is a Global Solutions Engineering Leader who leverages his website to establish his brand and build strong business relationships. Through his blog posts, Kester shares his expertise as a consultant, mentor, trainer, and presenter, providing innovative ideas and code examples to empower ambitious professionals.

backend connection reuse (1) backend sizing (1) best practices (1) cache filter (1) caching (1) caching strategy (1) CentOS (15) concurrency (1) connection multiplexing (1) connection pooling (2) Connector (5) Cooperative Monitoring (3) cpu (1) CPU cores (1) database benchmarking (1) diff router (5) High Availability (13) high concurrency (2) high concurrency databases (1) idle_session_pool_time (1) Java (3) load testing (1) MariaDB (27) MaxScale (30) MaxScale configuration (1) MaxScale multiplex_timeout (1) MaxScale threads (1) multi-threading (1) multiplexing (2) multiplex_timeout (1) OLTP (1) Performance Optimization (3) performance testing (1) performance tuning (2) performance tuning checklist (1) persistmaxtime (1) persistpoolmax (1) Python (2) Replica Rebuild (10) Rocky Linux (15) session sharing (1) Sysbench (1) thread architecture (1) tuning (1) upgrade (5)