我第一次踏进香港这家 IDC 机房的时候，空调的冷风还没吹散过道间那股铁皮和机柜混合的热气。手里拎着一台刚送到的 2U 高性能计算节点，心里已经在盘算：这台机器要承担我们大规模数据分析的核心任务，I/O 能不能顶住，直接关系到业务的生死。

CentOS 7 的环境我们很熟，但 HPC（高性能计算）场景里，CPU 跑得快，存储 I/O 不跟上，一切都是空谈。我决定从最底层 BIOS 开始，一路往上调优内核参数，走一遍“硬核实战”。这篇文章就是我的完整记录。

一、硬件环境与初始规划

1.1 硬件规格

1.2 初始目标

HPC 应用主要是分布式计算，I/O 模式以 小文件随机读写 和 顺序吞吐混合 为主。

希望 NVMe 盘组能做到接近物理极限的低延迟和高吞吐。

系统盘独立，避免 I/O 抢占。

二、BIOS 层优化：从硬件握手开始

在上电进入 BIOS 的那一刻，才算真正开启调优之路。

2.1 CPU 与电源管理

关闭 C-States：HPC 节点里 CPU 休眠带来的功耗收益微乎其微，但延迟上升明显。

Performance Profile 调为 Maximum Performance，避免 BIOS 自动调节频率。

2.2 内存与 NUMA

打开 NUMA Awareness，保证跨 Socket 的进程调度更精准。

设置 Memory Interleaving = Channel，提升带宽利用率。

2.3 存储控制器

MegaRAID 里把 Write Policy 改成 Write Back（有 BBU/CacheVault 才敢用）。

Cache Line Size 调大到 256KB，以适应 HPC 大块读写。

2.4 NVMe 优化

部分主板 BIOS 支持 NVMe OPROM 模式，我强制启用直通（Passthrough），避免冗余抽象层。

现场坑点：刚开始 RAID 控制器默认居然把 NVMe 当 SATA 逻辑卷挂，导致 IOPS 掉了一半。排查半天才发现，必须在 BIOS Storage Policy 里切换成 NVMe Direct.

三、CentOS 7 系统级准备

3.1 内核与驱动

CentOS 7 默认内核（3.10）太老，我选择 ELRepo 的 kernel-ml 5.4。既保持 CentOS 7 的兼容，又能获得 NVMe 与 RDMA 的新特性。

yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm -y
yum --enablerepo=elrepo-kernel install kernel-ml -y
grub2-set-default 0
reboot

3.2 文件系统

系统盘：xfs（稳定性第一）。

NVMe 数据盘：ext4 with -E stride=128,stripe-width=1024，配合 RAID 组。

启用 noatime 和 nodiratime。

挂载参数示例：

UUID=xxxx-xxxx /data ext4 defaults,noatime,nodiratime,barrier=0 0 2

四、内核参数调优

我在 /etc/sysctl.conf 中做了如下配置：

# I/O 调度
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
vm.swappiness = 1

# 提高读写并发
fs.file-max = 2097152
fs.aio-max-nr = 1048576

# TCP 优化（100GbE RDMA 需要）
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728

应用参数：

sysctl -p

五、I/O 调度器与多队列优化

5.1 NVMe 多队列（MQ）

CentOS 7 + 新内核，NVMe 默认是 mq-deadline 调度。我实测：

• mq-deadline 在混合负载下延迟更稳定；
• none 调度在大顺序读写下吞吐更高。

所以我为不同挂载点做了区分：

echo none > /sys/block/nvme0n1/queue/scheduler
echo mq-deadline > /sys/block/nvme1n1/queue/scheduler

5.2 调整 I/O 队列深度

默认 128 太保守，我改成 1024：

echo 1024 > /sys/block/nvme0n1/queue/nr_requests

六、实际测试与对比

我用 fio 做基准测试，结果如下：

关键提升点：BIO 调度器调整、NUMA 配置正确、以及 RAID 缓存策略。

七、现场遇到的坑与解决方案

坑一：MegaRAID 驱动版本冲突

现象：新内核下 megaraid_sas 模块报错，盘组掉线。

解决：下载 Broadcom 官方 DKMS 包，手工编译内核模块。

坑二：fio 测试结果不稳定

现象：第一次跑 IOPS 高，第二次骤降。

排查：发现是 dirty cache 没清，echo 3 > /proc/sys/vm/drop_caches 后恢复。

坑三：NUMA 跨 Socket 延迟过高

现象：进程绑定错误，I/O 延迟翻倍。

解决：用 numactl --cpunodebind=0 --membind=0 显式绑定进程。

八、总结：机房里的“安静高速公路”

当我最后一次在机房里执行 fio，看着监控面板上 IOPS 曲线平稳地贴近 NVMe 的理论极限时，那种感觉就像深夜走在一条空旷的高速公路上——安静、稳定、畅快。

这套优化过程不是一蹴而就的，中间踩过驱动的坑、RAID 策略的坑，也有 NUMA 配置错误带来的延迟。但正是这些坑让我对系统的每一层都有了更深的理解。

如果你也在香港机房里，面对一台等待上岗的 HPC 节点，我希望这篇文章能成为你的一盏灯。