5154

在现代化的多处理器服务器架构中,NUMA（Non-Uniform Memory Access，非统一内存访问）已成为一种标准设计，它通过将CPU和其本地内存组织成多个“节点”，旨在提升内存访问的并行度和带宽，在某些特定应用场景下，NUMA的复杂性反而会成为性能瓶颈，在CentOS 7这样的企业级操作系统上，了解并掌握如何关闭NUMA显得尤为重要，本文将深入探讨NUMA的工作原理、为何需要禁用它，以及在CentOS 7上进行操作的具体方法和验证手段。

理解NUMA架构及其潜在问题

NUMA架构的核心思想是解决多CPU系统下,所有CPU共享单一内存总线所带来的带宽瓶颈，在一个典型的双路服务器上，系统会存在两个NUMA节点，每个节点包含若干CPU核心和一部分直接连接的本地内存，当某个核心访问其所在节点的本地内存时，速度最快；而当它需要访问另一个节点的“远程内存”时，则必须通过互联模块（如Intel的QPI/UPI），这会引入额外的延迟。

这种设计在理论上非常高效,但在实际应用中，尤其是在运行某些特定软件时，会产生问题：

• 内存分配不均：操作系统默认的内存分配策略可能并不智能，一个进程（一个数据库服务）可能在NUMA节点0上运行，但其所需的数据却被分配到了节点1的内存中，这导致大量的“跨节点内存访问”，性能远不如访问本地内存，严重时甚至比传统SMP架构（对称多处理）还要差。
• 应用感知不足：许多老旧或未针对NUMA优化的应用程序（如早期版本的MySQL、Redis、Oracle数据库等）在运行时，它们并不知道自己正处在NUMA环境中，它们会向操作系统申请内存，而操作系统可能将内存分散在各个节点上，导致应用内部产生大量的远程访问，性能急剧下降。
• 虚拟化环境的挑战：在KVM等虚拟化环境中，如果一个虚拟机（VM）的vCPU和内存被分散分配到不同的物理NUMA节点上，其内部运行的应用同样会面临跨节点访问的延迟问题，严重影响虚拟机的性能表现。

正是由于这些原因,系统管理员在面对性能调优时，关闭NUMA，让系统退化为一个单一的、统一的内存访问模型，有时反而能获得更稳定、更可预测的性能。

在CentOS 7上关闭NUMA的方法

在CentOS 7中，关闭NUMA主要有以下几种方法，其影响范围和实施难度各不相同。

通过内核引导参数（最彻底）

这是最常用也是最彻底的方法,它在系统启动时就告知内核禁用NUMA支持，修改后，整个系统都将视自己为一个单一的NUMA节点。

操作步骤如下：

1. 编辑GRUB配置文件： 使用文本编辑器（如vi或nano）打开 /etc/default/grub 文件。

   sudo vi /etc/default/grub

2. 修改GRUB_CMDLINE_LINUX行： 找到以 GRUB_CMDLINE_LINUX 开头的行，该行包含了传递给内核的启动参数，在引号内的现有参数末尾，添加 numa=off。 原始行可能如下： GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet" 修改后应变为： GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet numa=off"

3. 重新生成GRUB配置： 保存文件后，需要根据系统的启动方式（BIOS或UEFI）重新生成GRUB2的配置文件，CentOS 7通常使用以下命令：

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg

   如果系统是UEFI启动,配置文件路径可能为 /boot/efi/EFI/centos/grub.cfg，但上述命令在大多数情况下能自动处理。

   

4. 重启系统： 完成以上步骤后，必须重启服务器才能使更改生效。

   sudo reboot

使用numactl命令（按需控制）

这种方法并非全局关闭NUMA,而是通过numactl工具来控制单个进程的NUMA策略，这对于不想全局禁用，但又想优化特定应用性能的场景非常有用。

要以“交错”策略启动MySQL服务，使其内存分配可以均匀分布在所有NUMA节点上，避免热点，可以使用：

numactl --interleave=all /usr/bin/mysqld_safe --user=mysql &

或者,强制将某个进程绑定到指定的NUMA节点上运行，确保其CPU和内存都在同一个节点内：

numactl --cpunodebind=0 --membind=0 /path/to/your/application

这种方法灵活,但需要为每个需要优化的应用单独配置。

在BIOS/UEFI中禁用

部分服务器主板允许在BIOS或UEFI设置中直接关闭NUMA,这种方法与内核参数效果类似，但操作层面在硬件固件，进入服务器的BIOS设置界面，寻找类似 "NUMA Architecture"、"Node Interleaving" 或 "Memory Interleaving" 的选项，并将其设置为 "Disabled" 或 "Enabled"（不同厂商的术语可能相反，需仔细阅读说明），此方法不常用，因为远程管理BIOS不如在操作系统内修改方便。

如何验证NUMA是否已禁用

在执行了关闭操作并重启后,需要验证NUMA是否真的被禁用了，可以使用以下命令：

1. 使用numactl工具： 如果系统已安装numactl，可以运行：

   numactl --hardware

   如果NUMA已启用,会显示详细的节点信息，如果已禁用，通常会提示 No NUMA support available on this system 或只显示一个节点（node 0）。

2. 使用lscpu命令： lscpu命令能清晰地展示CPU架构信息。

   

   lscpu

   在输出中查找 NUMA node(s) 这一行，如果NUMA已禁用，其值应为 1。

3. 检查dmesg内核日志： 内核启动日志中会记录NUMA的状态。

   dmesg | grep -i numa

   如果使用了numa=off参数，日志中通常会包含 NUMA: Disabled 或 No NUMA configuration found 等信息。

禁用NUMA的权衡利弊

关闭NUMA并非万能药,它是一把双刃剑，在决定是否禁用时，必须充分了解其带来的利与弊。

关闭NUMA是一种针对特定问题的“降级”方案，如果你的服务器运行着大量NUMA-aware（NUMA感知）的应用，或者工作负载是高度并行的科学计算，那么启用NUMA通常是更好的选择，反之，如果你正为老旧数据库的性能瓶颈而困扰，且排查后发现是NUMA导致的，那么果断关闭它将是合理的决策。

相关问答 (FAQs)

Q1: 我应该在所有的CentOS 7服务器上都禁用NUMA吗？

A1: 不应该，禁用NUMA是一项针对特定性能瓶颈的优化措施，而非通用最佳实践，如果你的服务器运行的是现代版本的、对NUMA架构有良好支持的应用程序（如最新的数据库、Web服务器、虚拟化平台等），启用NUMA通常能更好地利用硬件资源，获得更高的整体性能，只有在明确诊断出某个应用因为跨NUMA节点内存访问而出现严重性能问题时，才应该考虑禁用NUMA，对于大多数通用服务器场景，保持默认开启状态是更明智的选择。

Q2: 我已经通过内核参数numa=off禁用了NUMA，但某个应用的性能依然没有改善，接下来应该检查什么？

A2: 如果禁用NUMA后性能问题依旧，说明瓶颈可能不在NUMA架构本身，建议按以下步骤排查：

1. 再次确认：使用 lscpu 和 numactl --hardware 再次确认NUMA确实已被禁用。
2. 检查CPU频率和状态：使用 cpupower frequency-info 或查看 /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 确认CPU是否工作在预期频率，是否因节能策略而降频。
3. 分析I/O瓶颈：使用 iostat -x 1、sar -d 1 等工具检查磁盘I/O或网络I/O是否存在等待，性能瓶颈可能在于存储或网络而非CPU或内存。
4. 检查IRQ均衡：在多核系统中，中断（IRQ）是否均匀分布到所有CPU核心也很重要，可以使用 cat /proc/interrupts 查看中断分布情况，不均衡的IRQ可能导致某个核心负载过高。
5. 应用层面分析：使用 strace、perf 等工具对应用本身进行更深层次的性能分析，定位到具体的函数或系统调用，找到真正的性能瓶颈所在。