香港AMD EPYC 7313服务器部署后如何验收：CPU性能与磁盘I/O怎么测

常见的验收失败并不是服务器完全没有性能，而是测试对象和业务实际使用的资源不一致：CPU测试跑到了受限的 vCPU，磁盘测试却写在系统盘或缓存层，最终得出的结果无法代表业务环境。

验收香港AMD EPYC 7313服务器时，建议先确认实际分配的CPU线程数、测试文件所在挂载点和当前系统负载，再分别进行单线程、多线程及磁盘顺序与随机I/O测试。性能是否达标，应以交付前约定的基线、同一测试参数和现场日志为判断依据，不能直接套用网上的理论分数。

开始前的准备条件

以下命令以 Linux 为例，适用于常见的 Debian/Ubuntu、RHEL/Rocky/AlmaLinux 环境。Windows 服务器不能直接执行这些命令，应改用 DiskSpd 等 Windows 工具，并按盘符重新设计测试文件路径。

测试前先记录系统、CPU、虚拟化和磁盘信息：

date -Is
cat /etc/os-release
uname -r
lscpu
systemd-detect-virt || true
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL
df -hT
findmnt

重点确认以下内容：

lscpu 显示的 CPU 数量是否与交付配置一致，不要只根据 EPYC 7313 型号判断可用线程数。
测试机器是否为虚拟化环境，是否存在 vCPU 配额或 CPU 超售。
磁盘测试路径是否位于业务实际使用的挂载点，而不是临时盘、容器 OverlayFS 或系统盘。
测试期间是否有备份、数据库写入、日志轮转等高I/O任务。
磁盘测试需要写入测试文件，应预留足够空间，并尽量安排在业务低峰期。

如果系统中没有测试工具，先根据发行版安装。不要在未确认系统版本时混用包管理器：

command -v sysbench
command -v fio
command -v iostat

Debian/Ubuntu 可使用：

sudo apt-get update
sudo apt-get install -y sysbench fio sysstat

RHEL、Rocky、AlmaLinux 可使用：

sudo dnf install -y sysbench fio sysstat

如果仓库中没有 sysbench，应先确认已启用的仓库和系统版本，不要直接下载来源不明的二进制文件。安装工具本身不应修改业务服务配置，但仍建议在维护窗口内完成。

第一步：确认CPU实际可用资源

先查看系统暴露给当前实例的CPU数量：

nproc
lscpu

如果 nproc 的结果与交付单不一致，先不要跑性能测试。常见原因包括云平台只分配了部分 vCPU、容器设置了 CPU 配额，或者虚拟机启动配置未更新。

可以进一步查看 cgroup 限制：

cat /sys/fs/cgroup/cpu.max 2>/dev/null || true
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us 2>/dev/null || true
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us 2>/dev/null || true

使用 sysbench 测试单线程和多线程

CPU测试会占用处理器资源。正在运行数据库、编译任务或在线接口时，不建议直接使用全部线程压测。

先测试单线程性能：

sysbench cpu \
  --cpu-max-prime=20000 \
  --threads=1 \
  --time=60 \
  run | tee /tmp/sysbench-cpu-1t.txt

再根据当前实际可用线程数测试多线程性能：

THREADS=$(nproc)

sysbench cpu \
  --cpu-max-prime=20000 \
  --threads="$THREADS" \
  --time=60 \
  run | tee /tmp/sysbench-cpu-all.txt

两次测试至少记录以下字段：

events per second：单位时间完成的计算事件数，数值越高通常代表计算吞吐越高。
total time：完成测试所需时间。
threads：实际使用的线程数。
测试时间、系统负载、CPU数量和虚拟化状态。

单线程结果主要用于判断单核响应，多线程结果用于判断整体吞吐。如果单线程正常而多线程明显偏低，应优先检查 vCPU 配额、后台负载、NUMA分配和CPU频率，而不是立即判定处理器故障。

建议在相同维护窗口、相同参数下连续执行三次，并使用中位数作为现场记录。若结果波动明显，例如不同轮次相差约10%甚至更多，应先排除后台任务和降频因素，再决定是否复测。没有基线时，不要用网上的“理论跑分”作为唯一验收标准。

第二步：在正确挂载点测试磁盘I/O

先选择一个专用测试目录。例如业务数据实际位于 /data，可以使用 /data/acceptance-test。不要把下面的路径直接套到生产环境，必须替换为已确认的目标挂载点。

export TEST_DIR=/data/acceptance-test
export TEST_FILE="$TEST_DIR/fio-test.bin"
export TEST_SIZE=4G

df -hT "$TEST_DIR"
findmnt -T "$TEST_DIR"

如果测试目录不存在，应先确认 /data 已经正确挂载，再创建目录：

sudo mkdir -p "$TEST_DIR"

测试文件大小应根据剩余空间调整。空间不足时可以将 TEST_SIZE 改为 1G，但不同大小的结果不能直接与其他机器横向比较。测试前至少确认该目录有足够的可用空间，且不会覆盖已有业务文件。

先检查 fio 是否支持计划使用的I/O引擎：

fio --enghelp | grep -E 'libaio|io_uring|psync'

Linux 环境通常可以优先使用 libaio。如果系统不支持，应改用 psync，但此时队列深度和并发模型不同，结果只能与同样使用 psync 的基线比较。

测试顺序写入和顺序读取

顺序写入会真实产生磁盘写入，需确认维护窗口和空间条件：

fio --name=seq-write \
  --filename="$TEST_FILE" \
  --size="$TEST_SIZE" \
  --rw=write \
  --bs=1M \
  --ioengine=libaio \
  --iodepth=16 \
  --direct=1 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --group_reporting=1 | tee "$TEST_DIR/seq-write.txt"

写入完成后测试顺序读取：

fio --name=seq-read \
  --filename="$TEST_FILE" \
  --size="$TEST_SIZE" \
  --rw=read \
  --bs=1M \
  --ioengine=libaio \
  --iodepth=16 \
  --direct=1 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --group_reporting=1 | tee "$TEST_DIR/seq-read.txt"

direct=1 用于尽量绕过操作系统页缓存，但测试仍可能受到文件系统、RAID、云盘虚拟化层和存储控制器缓存影响。因此，fio 输出代表的是“该挂载点在当前系统栈下的表现”，不一定等同于物理裸盘性能。

如果业务是数据库或大量小文件读操作，还可以补充随机读测试：

fio --name=rand-read \
  --filename="$TEST_FILE" \
  --size="$TEST_SIZE" \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=32 \
  --direct=1 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --group_reporting=1 | tee "$TEST_DIR/rand-read.txt"

随机写会增加存储磨损并影响线上业务，不建议作为默认验收项目。确实需要测试时，应由业务负责人确认窗口、数据路径和回滚方式后再执行。

如何判断测试结果是否合格

CPU测试应对照交付前约定的基线，至少保证以下条件一致：

CPU线程数和测试参数一致；
单线程与多线程分别比较，不能混为一个分数；
测试期间无明显备份、编译、数据库整理等后台任务；
三次结果没有异常大幅波动；
CPU异常日志、虚拟化限制和降频因素已排除。

磁盘测试主要查看 fio 输出中的 BW、IOPS、平均延迟以及 clat percentiles。顺序读写重点关注吞吐，随机读重点关注 IOPS 和尾延迟。单看带宽很高并不代表业务体验正常，如果 95%、99% 延迟明显升高，接口或数据库仍可能出现卡顿。

测试过程中可在另一个终端观察设备状态：

iostat -xz 1 10

同时检查内核和系统日志：

sudo journalctl -k -b --since "30 min ago" --no-pager
sudo dmesg --level=err,warn

如果出现 I/O error、文件系统错误、设备重置或超时，不要为了得到更高分数反复执行写测试。应先保留 fio 输出、iostat 和日志，再检查磁盘挂载、云盘状态、RAID或存储服务状态。

服务层面的上线验证

CPU和磁盘性能通过后，还要确认部署的实际服务能够工作。服务名称和端口必须替换为现场配置：

SERVICE_NAME="your-service"
PORT="8080"

sudo systemctl is-active "$SERVICE_NAME"
sudo systemctl --no-pager --full status "$SERVICE_NAME"
sudo ss -lntp | grep -E ":${PORT}\b"
sudo journalctl -u "$SERVICE_NAME" --since "30 min ago" --no-pager

如果是HTTP服务，再使用应用实际提供的健康检查地址：

curl -fsS "http://127.0.0.1:${PORT}/health"

/health 只是示例，不能在未确认应用路由时直接套用。没有HTTP接口的服务，应使用对应客户端执行一次真实功能验证，例如登录、查询、读写或任务提交。判断部署成功的依据应包括服务状态正常、端口监听正确、功能返回符合预期，以及测试时间段内没有新增启动错误或I/O错误。

常见异常与回滚处理

CPU结果偏低：先检查 nproc、cgroup限制、系统负载、虚拟化状态和CPU频率；不要直接修改内核参数或强制绑定CPU。
磁盘结果偏低：确认 fio 测试文件所在挂载点、direct=1、I/O引擎和队列深度是否一致，再通过 iostat 判断是设备饱和、延迟升高还是测试路径错误。
fio提示空间不足或权限错误：停止测试，核对目录归属和可用空间，不要扩大测试文件覆盖范围。
日志出现I/O错误：立即停止写入测试，保留现场输出并联系存储或主机维护方，不要通过删除日志掩盖问题。
性能正常但应用异常：转向应用配置、连接池、数据库日志和服务依赖检查，CPU与磁盘验收通过不代表应用配置一定正确。

本次验收默认不修改 governor、挂载参数、RAID配置和数据库参数，因此回滚主要是停止测试并清理专用测试文件。确认文件确实由本次验收创建、且不包含业务数据后，再执行：

# 仅确认 TEST_FILE 是本次创建的独立测试文件后执行
rm -f -- "$TEST_FILE"

如果测试文件由 root 创建，删除前还要确认路径和文件归属，避免对生产目录使用通配符删除。

上线检查清单

CPU实际可用线程数与交付配置一致；
已记录操作系统、内核、虚拟化状态、测试时间和后台负载；
单线程、多线程CPU结果已保存，并完成重复性检查；
fio测试文件位于业务目标挂载点，参数和I/O引擎已记录；
顺序读写或随机读结果包含带宽、IOPS和延迟信息；
iostat、内核日志和服务日志没有新增异常；
服务处于 active 状态，端口监听正常，实际功能验证通过；
验收测试文件已确认并清理，磁盘空间恢复；
若结果不达标，已保留日志和输出，未在未确认原因前修改生产配置。

服务器验收 CPU测试磁盘I/O fio测试部署验证

上一篇 香港服务器如何用MTR验证网络丢包：关键输出与判断标准 下一篇 在香港AMD EPYC 4585PX服务器部署Web业务：反向代理与进程守护如何配置