mysql在numa服务器上出现swap抖动和响应延迟波动，大概率是内存被错误分配到远端节点所致；需用numactl绑定cpu与内存节点、禁用transparent_hugepage、验证numa_hit>90%及页帧物理归属，并根据负载类型选择--membind或--interleave策略。
MySQL在NUMA服务器上出现swap抖动、响应延迟波动，大概率不是内存不够，而是内存被错误地分配到了远端节点——numactl必须介入，且不能只靠--interleave all一招打天下。
查清当前mysqld到底在哪个NUMA节点上跑
别信top或htop显示的CPU占用率，它们不反映内存归属。真正要看的是进程绑定状态和内存实际落点：
- 运行
numactl --show确认系统默认策略（通常是preferred或localalloc） - 用
cat /proc/$(pgrep mysqld)/status | grep -i "mem"查CapBnd和MMU相关字段，但更关键的是看numastat -p $(pgrep mysqld) - 重点盯
Heap行的numa_hit占比：低于90%就说明大量内存访问跨节点了 - 如果
numa_miss和numa_foreign持续高于5%，基本可断定Buffer Pool正在被远程节点“截胡”
禁用transparent_hugepage是硬性前提
numactl --membind对大页无效，内核会绕过你的绑定策略直接从任意节点分配2MB页。不关它，其他所有操作都白搭：
- 检查状态：
cat /sys/kernel/mm/transparent_hugepage/enabled，若输出含[always]或[madvise]，必须改 - 临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久生效：在
/etc/default/grub的GRUB_CMDLINE_LINUX里加transparent_hugepage=never，再update-grub && reboot - 验证是否生效：
grep AnonHugePages /proc/meminfo应为0
根据负载类型选绑定策略，不是所有场景都适合--interleave all
--interleave all看似省事，实则让Buffer Pool页帧随机散落在各节点，InnoDB线程访问时仍可能触发跨节点访问——尤其当innodb_buffer_pool_instances数远小于NUMA节点数时。
- 单实例高吞吐（如OLTP主库）：用
numactl --cpunodebind=0 --membind=0，强制全部落在Node 0，前提是innodb_buffer_pool_size≤ Node 0可用内存 × 0.8 - 多实例或混合负载（如备库+ETL）：用
numactl --interleave=all，但必须同步调大innodb_buffer_pool_instances（建议≥ NUMA节点数） - 绝对不要在systemd服务里直接写
ExecStart=numactl ... mysqld：systemd默认禁止CAP_SYS_NICE，会导致绑定失败；必须加CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE - 避免用
mysqld_safe启动：它会覆盖numactl环境，改用直接调用mysqld二进制
验证Buffer Pool物理位置是否真“落地”
SHOW ENGINE INNODB STATUS里的Buffer pool hit rate只管逻辑命中，不管物理在哪。要确认页帧归属，得看内核映射：
- 执行
sudo cat /proc/$(pgrep mysqld)/numa_maps | awk '$NF ~ /heap/ {print $4}' | sort | uniq -c - 理想输出应类似
123456 N0=123456或123456 interleave:0，而非N1=或interleave:1 - 如果仍有远端节点标识，检查是否有后台线程（如
log_writer）被调度到其他CPU：用ps -T -p $(pgrep mysqld) -o pid,tid,psr,comm看线程psr列是否漂移 - InnoDB内部线程无法用
numactl单独绑定，只能靠taskset配合mysqld启动前预设CPU亲和性，或升级到MySQL 8.0.30+启用innodb_numa_interleave
最易被忽略的一点：即使numastat显示numa_hit达标，只要vmstat里so值间歇跳升，就要立刻查/proc/zoneinfo中各Node的pages free和nr_inactive_anon是否严重失衡——NUMA导致的swap，从来不是因为总内存不够，而是某个Node的free + nr_inactive_file之和跌破high水位触发的局部回收。
