NUMA架构下的数据库性能优化：CPU绑核、内存交错与跨Node访问延迟

NUMA架构下的数据库性能优化：CPU绑核、内存交错与跨Node访问延迟

一、128核的机器跑MySQL，QPS为什么只有预期的一半

现代服务器普遍采用NUMA架构，一台典型的双路服务器有2个NUMA Node，每个Node拥有自己的CPU和本地内存。数据库进程在操作系统默认调度下可能在Node间频繁迁移，CPU访问远端内存的延迟是本地内存的1.5到2倍——这个差异在高并发OLTP场景下被数十万次的放大，最终表现为吞吐量远低于硬件理论值。

一个真实场景：在一台双路EPYC服务器上部署MySQL 8.0，128核、512GB内存、NVMe SSD。按理论计算，单机应该轻松跑到50万QPS。但实际压测只跑到22万QPS，CPU利用率仅35%。perf top显示mutex_spin_on_owner和native_queued_spin_lock_slowpath占了15%的CPU，大量的时间花在了锁等待上，而这些等待的根因是跨NUMA Node的内存访问延迟放大了临界区的持有时间。InnoDB的Buffer Pool分配在单一Node上，但工作线程分布在不同Node上，导致超过60%的内存访问都是跨Node的。这个场景不是个案——在未做NUMA优化的数据库部署中，性能损失30%-50%是常态。

二、NUMA的内存亲和性：本地访问与远端访问的天壤之别

NUMA的全称是Non-Uniform Memory Access（非一致性内存访问），核心特征是每个CPU有自己"近"的本地内存和"远"的远端内存。访问本地内存延迟约80-100ns，远端约140-200ns，差了近一倍。带宽差异更大——单个CPU的内存控制器带宽约200GB/s，但跨CPU访问需要通过UPI/InfinityFabric互联，有效带宽只有本地的一半甚至更低。

数据库在NUMA上有三种内存分配策略。localalloc是默认策略——进程在哪个Node上运行就从哪个Node分配内存，简单但会导致所有内存集中在一个Node，其他Node内存闲置。interleave将内存轮流分配到所有Node上，避免某个Node内存耗尽，但牺牲了内存局部性。preferred指定首选Node，内存优先从该Node分配，该Node满了才从其他Node分配。对于单实例MySQL，preferred策略配合CPU绑定是最优选择；对于多实例部署，每个实例绑定到不同的Node并强制localalloc。

三、基于libnuma的CPU绑核与内存策略实现

import ctypes import os import subprocess import logging from dataclasses import dataclass from typing import List, Dict, Optional import re logger = logging.getLogger(__name__) @dataclass class NumaNode: """NUMA Node信息""" node_id: int cpu_ids: List[int] total_memory_mb: int free_memory_mb: int cpu_count: int class NumaOptimizer: """NUMA优化的数据库部署工具""" def __init__(self): self.nodes: Dict[int, NumaNode] = {} self._parse_numa_topology() def _parse_numa_topology(self): """解析系统NUMA拓扑""" try: output = subprocess.check_output( ['numactl', '--hardware'], stderr=subprocess.STDOUT, text=True ) except (subprocess.CalledProcessError, FileNotFoundError) as e: logger.error(f"Failed to get NUMA topology: {e}") raise RuntimeError("NUMA topology unavailable - is numactl installed?") current_node = None for line in output.split('\n'): node_match = re.match(r'node (\d+) cpus:', line) if node_match: current_node = int(node_match.group(1)) cpu_str = line.split(':', 1)[1].strip() cpu_ids = [int(c) for c in cpu_str.split()] self.nodes[current_node] = NumaNode( node_id=current_node, cpu_ids=cpu_ids, total_memory_mb=0, free_memory_mb=0, cpu_count=len(cpu_ids), ) elif 'size' in line and current_node is not None: size_match = re.search(r'size:\s*(\d+)\s*MB', line) if size_match: self.nodes[current_node].total_memory_mb = int(size_match.group(1)) elif 'free' in line and current_node is not None: free_match = re.search(r'free:\s*(\d+)\s*MB', line) if free_match: self.nodes[current_node].free_memory_mb = int(free_match.group(1)) logger.info(f"NUMA topology: {len(self.nodes)} nodes") for nid, node in self.nodes.items(): logger.info( f" Node {nid}: {node.cpu_count} CPUs, " f"{node.free_memory_mb}/{node.total_memory_mb} MB free" ) def bind_mysql_to_node( self, pid: int, node_id: int, memory_policy: str = "preferred" ) -> bool: """将MySQL进程绑定到指定NUMA Node""" if node_id not in self.nodes: logger.error(f"Invalid NUMA node: {node_id}") return False node = self.nodes[node_id] cpu_list = ','.join(str(c) for c in node.cpu_ids) try: # CPU绑定 subprocess.run( ['taskset', '-a', '-cp', cpu_list, str(pid)], check=True, capture_output=True, text=True ) logger.info(f"Bound PID {pid} CPUs to node {node_id}: {cpu_list}") if memory_policy == "preferred": # 优选本地Node分配内存（numactl --preferred） subprocess.run( ['migratepages', str(pid), str(node_id)], check=False, capture_output=True, text=True ) elif memory_policy == "interleave": # 交错分配 all_nodes = ','.join(str(n) for n in self.nodes.keys()) subprocess.run( ['numactl', '--interleave=' + all_nodes, '--', 'echo', 'test'], check=True, capture_output=True, text=True ) return True except subprocess.CalledProcessError as e: logger.error(f"NUMA binding failed: {e.stderr}") return False def optimize_mysql_config(self, node_id: int) -> Dict[str, str]: """根据NUMA节点信息生成MySQL优化配置""" if node_id not in self.nodes: return {} node = self.nodes[node_id] # Buffer Pool分配在每个NUMA Node内存的60% bp_size_mb = int(node.free_memory_mb * 0.6) config = { 'innodb_buffer_pool_size': f'{bp_size_mb}M', 'innodb_buffer_pool_instances': str(min(16, node.cpu_count // 4)), 'innodb_read_io_threads': str(max(4, node.cpu_count // 8)), 'innodb_write_io_threads': str(max(4, node.cpu_count // 8)), # NUMA交错分配避免单Node OOM 'innodb_numa_interleave': 'ON', } logger.info( f"Generated config for node {node_id}: " f"buffer_pool={config['innodb_buffer_pool_size']}, " f"instances={config['innodb_buffer_pool_instances']}" ) return config def verify_numa_binding(self, pid: int) -> Dict[str, any]: """验证NUMA绑定效果""" result = { 'pid': pid, 'cpu_affinity': [], 'memory_nodes': {}, } try: # 检查CPU亲和性 output = subprocess.check_output( ['taskset', '-cp', str(pid)], text=True ) affinity_match = re.search(r'list:\s*([0-9,\-]+)', output) if affinity_match: result['cpu_affinity'] = affinity_match.group(1) # 检查内存分布 output = subprocess.check_output( ['numastat', '-p', str(pid)], text=True ) for line in output.split('\n'): parts = line.split() if len(parts) >= 2 and parts[0].startswith('Node'): try: node_id = int(parts[0].replace('Node', '')) result['memory_nodes'][node_id] = int(parts[1]) except (ValueError, IndexError): continue logger.info(f"NUMA verification for PID {pid}: {result}") except Exception as e: logger.error(f"NUMA verification failed: {e}") return result

关键操作流程：先用numactl --hardware获取NUMA拓扑；用taskset将MySQL的所有线程绑定到指定Node的CPU集合；设置innodb_numa_interleave=ON让Buffer Pool在分配时交错到多个Node；或者更激进的做法，让MySQL使用libnumaAPI在分配大块内存时指定Node。MySQL 8.0.14+支持innodb_numa_interleave参数，设置后InnoDB在分配Buffer Pool时会调用mbind()交错分配到所有Node。

四、容器环境的NUMA暴露：cpuset与NUMA拓扑的踩坑记录

容器化部署时NUMA优化面临的第一个问题是抽象层的缺失。默认情况下Docker不使用cpuset cgroup，容器内看不到宿主机的NUMA拓扑——numactl --hardware显示只有一个Node，所有内存都是"本地"的，但实际上仍然存在跨Node访问。解决办法是在容器启动时使用--cpuset-cpus和--cpuset-mems参数指定CPU和内存Node。

Kubernetes的NUMA支持在1.18引入了Topology Manager，但默认策略是none，不感知NUMA。需要将CPU Manager策略设为static，Topology Manager策略设为single-numa-node或best-effort。配置后kubelet在分配Pod时会尽量将CPU和内存放在同一个NUMA Node上。但有几个坑：资源碎片化（某Node的CPU够了但内存不够导致Pod无法调度）；DaemonSet中的组件如node-exporter无法绑定到特定Node；Golang runtime的GOMAXPROCS可能远大于分配的CPU核数导致过度调度。

NUMA感知对锁争用的影响容易被忽略。如果Buffer Pool在Node0，但InnoDB的锁管理结构（lock_sys->mutex）在Node1，每次加锁都要跨Node访问，锁的持有时间延长，吞吐量进一步下降。解决方式是用numactl --membind强制所有的匿名内存分配在指定Node上。

五、总结

NUMA优化是数据库性能调优的第二个层次——在SQL优化、索引优化、连接池配置等"软件层"优化完成后，硬件拓扑的感知能带来额外的30%-50%性能提升。核心原则只有一条：让线程跑在使用其数据的CPU上，让数据放在使用它的CPU的内存中。关键操作是CPU绑核和内存策略配置。在多实例部署场景中，每个MySQL实例独立绑定到一个NUMA Node是最佳实践。单实例大规格部署则建议启用innodb_numa_interleave避免单Node内存耗尽。容器化环境中NUMA的暴露需要额外配置，Topology Manager的选型和验证是上线前的必要步骤。