把机器逼到极限：openEuler 极限性能优化实战

——Echo_Wish 跟你唠唠性能那些事儿

兄弟姐妹们，说到“极限性能”，很多人脑子里立刻冒出一句话：“把所有参数都调到最大”。别逗了，那样只会把系统推向不稳定边缘，自己还蒙在鼓里。性能优化不是“狂野生长”，而是“有针对性的工程化手术”。今天咱就聊聊在 openEuler（一台企业级 Linux）的世界里，如何系统性地做极限性能优化：思路、工具、策略、以及实战命令和脚本，保证既稳又快。

一、优化的三条铁律（先立规矩再开刀）

1. 可量化目标：先用 benchmark（fio、sysbench、wrk、iperf）量化基线，再改参数。
2. 小步迭代：一次改一类参数，记录和比对，别一次性改一堆。
3. 优先级排序：定位瓶颈（CPU / IO / 网络 / 内存 / NUMA），按瓶颈有目标地优化。

二、先把“看病”的工具准备好

• top / htop：快速看 CPU 与负载。
• vmstat / iostat：IO 与内存统计。
• perf：看函数级热点、上下文切换、缓存失效。
• dstat：综合资源趋势。
• numactl / numastat：NUMA 分布与内存亲和性。
• sar（sysstat）：长期性能数据。
• tcpdump / ss / ip：网络排查。
• fio、sysbench、wrk：压力测试。

举个简单的 baseline 测试脚本（参考）：

# baseline_test.sh
#!/bin/bash
echo "Collecting baseline..."
vmstat 1 5 > vmstat.out &
iostat -x 1 5 > iostat.out &
sar -n DEV 1 5 > netstat.out &
sleep 6
fio --name=randrw --rw=randrw --bs=4k --size=2G --numjobs=4 --runtime=60 --group_reporting > fio.out

三、CPU 层面的“细致活儿”

1. CPU 亲和性与中断（IRQ）绑定

高并发场景下，频繁的上下文切换会扼杀吞吐。把关键进程和中断绑定到固定 CPU，可以降低抖动：

# 把进程 pid 绑定到 cpu 2 和 3
taskset -p -c 2,3 <pid>

# 查看 IRQ 分布
cat /proc/interrupts

# 示例：把 eth0 的 rx irq 绑定到 cpu4-7（根据系统调整）
echo 0xF0 > /proc/irq/<IRQ_NUM>/smp_affinity

2. 调度器 & CFS 调整

对于延迟敏感型应用，可调整 CFS 参数（sched_min_granularity_ns、sched_latency_ns）或使用 isolcpus、nohz_full 来隔离 CPU，减少内核干扰。

# kernel boot 参数（/etc/grub2.cfg）
# isolcpus=4-7 nohz_full=4-7

四、内存与 NUMA：不要让远端内存来回跑

在多路 NUMA 系统上，线程和内存在不同节点会产生远端访问延迟。使用 numactl 强制在本地分配内存与进程亲和：

# 在 NUMA node 0 上运行程序，并绑定内存在 node0
numactl --cpunodebind=0 --membind=0 ./your_app

另外，HugePages 对于数据库或高性能网络转发非常关键，能减少 TLB miss：

# 临时开启 2M HugePages
echo 1024 > /proc/sys/vm/nr_hugepages

五、存储 IO：吞吐还是 IOPS？先搞清楚

不同场景关注点不同：数据库关注 IOPS 与延迟，流式写日志关注吞吐。优化手段包括：

1. 文件系统选择与挂载选项

• XFS 对并发写表现好，ext4 稳定。
• 挂载时可根据场景使用 noatime, nodiratime, data=writeback（慎用）等。

2. 调整块设备调度器

• mq-deadline 或 bfq 对延迟敏感型好，noop 适合硬件有自己调度（NVMe）时：

# 临时切换调度器
echo mq-deadline > /sys/block/nvme0n1/queue/scheduler

3. 调整 IO 深度与并发（fio 示例）

fio --name=bench --ioengine=libaio --rw=randread --bs=4k --size=10G --numjobs=8 --iodepth=64

六、网络栈：吞吐与延迟并非一箭双雕

网络优化要看应用：RPC/微服务 vs 大流量传输。

1. tcp 参数调优（示例）

# /etc/sysctl.conf
net.core.netdev_max_backlog=50000
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 65536 134217728
net.ipv4.tcp_congestion_control=bbr    # 如果 kernel 支持 bbr，优先尝试

修改后执行 sysctl -p。

2. 中断与 RSS（接收端分散）

确保 NIC 的 RSS 与中断分布能把流量均匀分到 CPU 核心上。

七、容器/虚拟化下的性能策略（openEuler 也常跑容器）

• 使用 cgroups v2 做资源隔离和限制（避免 noisy neighbor）。
• 给关键容器设置 cpu、memory、hugepages 限额与亲和性。
• 在容器里仍然做 numactl 和 taskset 亲和。

示例 Pod/容器资源配置（K8s）略示意（在 openEuler 环境常见）：

resources:
  limits:
    cpu: "4"
    memory: "8Gi"
    hugepages-2Mi: "1Gi"

八、观察与自动化：把优化做成可复现的流程

• 把基线测试、每次调优的结果写成 CI 流程（Jenkins/GitLab CI），自动跑 benchmark。
• 用 Prometheus + Grafana 记录基线与调优后的指标对比。
• 使用脚本化（Ansible）推参数，保证环境一致性。

九、实战小案例：把数据库 TPS 提升 30% 的思路（举例）

1. 用 sysbench 测基线，发现 CPU 70% 未饱和，IO 延迟高。
2. 调整文件系统为 XFS，挂 noatime；切换 IO 调度到 mq-deadline。
3. 开启 HugePages，绑定 DB 进程到 NUMA node，减少远端内存访问。
4. 优化 kernel tcp/内核参数，避免网络成为瓶颈（主从 replication 高并发）。
5. 复测：IO 延迟下降、TPS 提升约 25-35%。

十、Echo_Wish 的收尾感悟（带点温度）

性能优化不是“单枪匹马的炫技”，它更像是团队一起做的手术：需要数据来诊断，需要策略来开刀，需要工具来缝合，需要监控来复诊。openEuler 作为企业级发行版，给我们提供了稳定与可控的内核与系统工具，但真正把机器逼到极限的，是你对应用、硬件、内核三者交互的深刻理解。