服务器运维工作中，硬件性能测评是物理机架设和云服务器选型的关键依据。单纯查看CPU型号或内存频率不等于了解实际负载能力。本文使用stress-ng和fio两款工具，对CPU、内存、磁盘I/O三个维度进行标准化压力测试，并给出结果分析方法。
环境准备与工具安装
测试环境为Ubuntu 22.04 LTS，内核版本5.15以上。安装所需工具：
# 更新软件包索引
apt update
# 安装压力测试工具
apt install -y stress-ng fio sysstat htop
# 验证安装
stress-ng --version
fio --version
# 记录硬件信息作为基准
lscpu | grep -E "Model name|CPU\(s\)|Thread|Core|Socket"
free -h
lsblk -d -o NAME,SIZE,TYPE,ROTA,MODEL
dmidecode -t memory | grep -E "Size|Speed|Type:"
正式测试前关闭不必要的后台服务，减少噪声干扰：
# 停止非必要服务
systemctl stop snapd
systemctl stop unattended-upgrades
# 记录测试前温度基线
sensors || apt install -y lm-sensors && sensors-detect --auto
sensors | grep -E "Core|Package|temp"
CPU压力测试：stress-ng多维度基准
stress-ng比传统stress工具覆盖更全面的CPU指令集测试。服务器故障排查中，CPU测试不仅验证算力，还检测散热稳定性和降频问题。
# 基础CPU负载测试：所有核心满载60秒
stress-ng --cpu $(nproc) --cpu-load 100 --timeout 60s --metrics-brief
# 输出示例：
# stress-ng: info: [12345] setting to a 60 secs run per stressor
# stress-ng: info: [12345] dispatching hogs: 64 cpu
# stress-ng: info: [12345] successful run completed in 60.00s
# stress-ng: info: [12345] stressor bogo ops real time usr time sys time
# stress-ng: info: [12345] cpu 65536 60.00s 3840.00s 0.05s
# 针对特定指令集的测试（更贴近实际业务负载）
# 浮点运算测试（适合科学计算场景）
stress-ng --cpu $(nproc) --cpu-method matrixprod --timeout 120s --metrics-brief
# 整数运算测试（适合Web服务器场景）
stress-ng --cpu $(nproc) --cpu-method int32 --timeout 120s --metrics-brief
# 混合负载测试：CPU + 矩阵运算 + 上下文切换
stress-ng --cpu 4 --matrix 4 --switch 4 --timeout 120s --metrics-brief \
--tz --thermal-stat
测试过程中同步监控频率和温度，检测是否存在热降频：
# 每2秒记录一次CPU频率和温度
while true; do
echo "$(date +%H:%M:%S) \
$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq) \
$(sensors | grep 'Package id 0' | awk '{print $4}')"
sleep 2
done
# 快速检测降频：对比标称频率与实测频率
BASELINE_FREQ=$(lscpu | grep "MHz" | head -1 | awk '{print $NF}')
echo "标称频率: ${BASELINE_FREQ}MHz"
echo "实测频率: $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)"
内存带宽与稳定性测试
内存测试关注两个指标：带宽吞吐和错误检测。高可用集群中内存ECC错误是服务器故障排查的重要线索。
# 内存带宽测试：多线程读写
stress-ng --vm $(nproc) --vm-bytes 80% --vm-method read --timeout 60s --metrics-brief
# 内存压力测试：检测稳定性
# 分配总内存的75%，避免触发OOM Killer
TOTAL_MEM=$(free -b | awk '/Mem:/ {print $2}')
TEST_MEM=$((TOTAL_MEM * 75 / 100))
stress-ng --vm 4 --vm-bytes $((TEST_MEM / 4)) --vm-method write \
--timeout 300s --metrics-brief --vm-keep
# 检查ECC错误（需要内核支持）
edac-util -v 2>/dev/null || \
cat /sys/devices/system/edac/mc/mc0/ce_count 2>/dev/null || \
echo "EDAC不可用，检查dmesg"
dmesg | grep -iE "edac|memory|error|mce" | tail -20
磁盘I/O测试：fio全场景基准
fio是Linux系统管理中最灵活的I/O测试工具。不同业务场景的I/O模式差异很大，需要针对性测试。
随机读写测试（数据库场景）
# 4K随机读测试：模拟OLTP数据库负载
fio --name=rand_read --ioengine=libaio --iodepth=32 \
--rw=randread --bs=4k --direct=1 --numjobs=4 \
--size=4G --runtime=120 --time_based --group_reporting
# 4K随机写测试
fio --name=rand_write --ioengine=libaio --iodepth=32 \
--rw=randwrite --bs=4k --direct=1 --numjobs=4 \
--size=4G --runtime=120 --time_based --group_reporting
# 混合随机读写（70%读30%写，贴近生产环境）
fio --name=mixed_rw --ioengine=libaio --iodepth=32 \
--rw=randrw --rwmixread=70 --bs=4k --direct=1 \
--numjobs=4 --size=4G --runtime=120 --time_based --group_reporting
顺序读写测试（文件服务器/备份场景）
# 1M顺序读：测试最大读取带宽
fio --name=seq_read --ioengine=libaio --iodepth=16 \
--rw=read --bs=1M --direct=1 --numjobs=1 \
--size=16G --runtime=120 --time_based --group_reporting
# 1M顺序写：测试最大写入带宽
fio --name=seq_write --ioengine=libaio --iodepth=16 \
--rw=write --bs=1M --direct=1 --numjobs=1 \
--size=16G --runtime=120 --time_based --group_reporting
结果解读要点：
| 指标 | 含义 | 参考值（NVMe SSD） | 参考值（SATA SSD） |
|---|---|---|---|
| IOPS | 每秒I/O操作数 | 100K-500K | 30K-90K |
| bw（带宽） | 每秒数据吞吐量 | 2000-7000 MiB/s | 500-550 MiB/s |
| lat（延迟） | 单次I/O响应时间 | 50-200us | 100-500us |
| clat（完成延迟） | I/O完成等待时间 | 查看P99值 | 查看P99值 |
综合负载测试与瓶颈定位
实际生产环境中的负载是CPU、内存、I/O的混合压力。综合测试能暴露资源竞争导致的性能下降。
# 同时施加CPU、内存、I/O压力
# 终端1：CPU满载
stress-ng --cpu $(nproc) --cpu-load 90 --timeout 300s &
# 终端2：I/O压力
fio --name=combined_io --ioengine=libaio --iodepth=16 \
--rw=randrw --rwmixread=70 --bs=4k --direct=1 \
--numjobs=2 --size=2G --runtime=300 --time_based &
# 终端3：监控关键指标
sar -u -r -d 5 60 | tee /tmp/sar_monitor.log
# 综合测试后检查：是否有性能异常下降
echo "=== CPU利用率 ==="
sar -u -f /tmp/sar_monitor.log | awk 'NR>3 {print $1, $2, "idle:"$NF}'
echo "=== 内存使用 ==="
sar -r -f /tmp/sar_monitor.log | awk 'NR>3 {print $1, $2, "memused:"$4"%"}'
echo "=== 磁盘I/O ==="
sar -d -f /tmp/sar_monitor.log | awk 'NR>3 {print $1, $2, "await:"$10}'
瓶颈定位方法：如果综合测试中IOPS相比单独测试下降超过30%，说明CPU或内存竞争影响了I/O性能。此时需要检查irqbalance是否正确分配了NVMe中断到不同NUMA节点：
# 查看NVMe设备的中断分配
cat /proc/interrupts | grep nvme
# NUMA亲和性检查
numactl --hardware
cat /sys/block/nvme0n1/device/numa_node
IDC数据中心服务器选型时，通过标准化测试数据横向对比不同机型。建议建立测试基线数据库，记录每批服务器的测试结果，长期跟踪硬件老化趋势。服务器安全加固方面，压力测试过程中注意监控系统日志，高温满载场景可能暴露供电或散热设计缺陷。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/fu-wu-qi-ying-jian-xing-neng-ce-ping-shi-zhan-shi-yong/
