AMD EPYC 4584PX香港服务器虚拟化性能怎么测？看CPU、内存与I/O指标

AMD EPYC 4584PX 香港服务器的虚拟化性能，不能只看一次 CPU 跑分或磁盘顺序读写速度。更有参考价值的做法，是在确认 CPU 型号、虚拟化方式和资源配额后，分别测单核与多核计算、内存带宽与延迟、磁盘 IOPS 与尾延迟，再用并发负载观察指标如何变化。这样才能判断瓶颈来自处理器、内存、存储，还是虚拟机之间的资源争用。

测试前先记录宿主机和虚拟机的配置，并确认是在 KVM 等虚拟化环境中测试。相同的 CPU 型号，可能因 BIOS 设置、内存通道、NUMA 拓扑、云平台配额及存储后端不同而表现不同；如果这些条件没有记录，跑分数字就很难复现，也不适合直接比较。

一、先把测试环境固定下来

测试应记录的内容至少包括：

在虚拟机中，可先用以下命令检查系统报告的处理器和内存信息：

lscpu
free -h
grep -E 'model name|processor' /proc/cpuinfo | head

如果系统提供了 systemd-detect-virt，也可以用它确认虚拟化环境：

systemd-detect-virt

这里看到的 CPU 型号、核心数和内存都是虚拟机可见信息，不一定完整反映宿主机实际配置。例如，虚拟机可能只获得部分 vCPU，也可能运行在共享 CPU 池中。不要仅凭系统显示的最高频率推断持续性能；频率会随负载、温度、功耗和调度变化。

建议使用同一操作系统、相同测试工具版本和一致的虚拟机配置进行复测。若要比较不同配置，应一次只改变一个变量，例如固定 vCPU 数，仅改变内存；或固定虚拟机配置，仅改变并发数。否则，即使结果不同，也难以定位原因。

二、CPU：区分单核响应与多核吞吐

CPU 测试至少要覆盖两类负载：

• 单线程测试：反映单个任务的计算响应能力，适合观察轻量服务、短请求或单线程任务。
• 多线程测试：反映多个 vCPU 同时工作时的整体吞吐，适合观察并行编译、批量计算和多进程服务。

可以用 sysbench 做基础 CPU 测试。以下命令运行 60 秒，分别测试单线程和 4 线程；线程数应按虚拟机实际分配的 vCPU 调整。

sysbench cpu --threads=1 --time=60 run
sysbench cpu --threads=4 --time=60 run

重点记录每秒事件数（events per second）、总事件数和运行时间。单线程结果偏低，可能与虚拟 CPU 频率、宿主机调度或测试环境负载有关；多线程结果没有随线程数增加而相应提升，则可能是 vCPU 配额、CPU 争用、任务本身不能充分并行，或共享资源限制导致。

不要把“4 线程分数是单线程的几倍”当成固定标准。实际并行效率取决于工作负载：能并行拆分的计算任务可能接近线性扩展；有锁竞争、串行步骤或内存等待的任务，扩展会明显变慢。更可靠的做法是同步记录 CPU 使用率与 steal time：

top

如果系统安装了 sysstat，可用以下命令按秒观察 CPU 状态：

mpstat -P ALL 1 60

在输出中关注 %usr、%sys、%idle 和 %steal。%steal 表示虚拟机等待宿主机调度 CPU 的时间比例。若负载期间 steal time 持续升高，同时吞吐下降或响应时间变长，说明虚拟机可能受到 CPU 争用影响；但短时出现少量波动，不足以单独证明宿主机过载。还要结合测试时段、其他进程活动和多次重复结果判断。

测 CPU 时不应只跑一次。可先空闲观察 1 分钟，再运行基准测试 60 秒，重复 3 至 5 轮；记录每轮结果和中位数，同时保留最低、最高值。如果结果离散较大，优先查后台任务、资源争用和调度波动，而不是只挑最高分作为代表。

并发测试要看吞吐，也要看延迟

单个虚拟机的多线程跑分不能完整反映实际服务承载能力。对于 Web 服务、应用进程或多租户任务，可以按 1、2、4、8 等并发档位逐步增加负载，并记录：

• 每秒完成请求数或任务数，即吞吐；
• 平均响应时间；
• P95、P99 等高分位延迟；
• CPU 利用率与 steal time；
• 错误率和超时数量。

例如，并发从 1 提升到 4 后，吞吐提高，但 P99 延迟大幅增长，说明系统仍能处理更多工作，却开始让部分请求等待更久。若吞吐不再明显增加、CPU 接近持续满载，且延迟继续上升，CPU 或调度可能已成为瓶颈。若 CPU 并未打满，不能立刻归因于处理器，还需检查内存等待、磁盘 I/O、锁竞争和应用自身的并行能力。

三、内存：带宽、延迟与容量压力要分开看

内存性能至少要区分三个概念：

• 容量：虚拟机能够使用多少内存，以及负载增长后是否触及上限。
• 带宽：单位时间内能够传输多少数据，影响大规模数据处理和内存密集型任务。
• 延迟：一次内存访问需要等待多久，对随机访问和部分数据库负载较敏感。

可以用 sysbench 做基础内存吞吐测试：

sysbench memory --threads=1 --time=60 run
sysbench memory --threads=4 --time=60 run

重点记录传输速度和总传输量，并确保不同测试使用相同的内存操作方式与块大小。该类基准适合做同一环境内的相对比较，不等同于所有应用的真实内存带宽，也无法单独说明随机访问延迟。若需要观察实际业务表现，应再以目标应用或更贴近业务的数据访问模式补测。

测试时要检查内存是否充足以及是否发生交换：

free -h
vmstat 1 60

free -h 用于查看总量、已用量和可用量；vmstat 中的 si、so 分别表示交换空间读入和写出。持续出现交换活动，通常意味着当前内存压力已影响测试结果。此时测到的可能是“内存不足后系统如何退化”，而不是内存本身的正常吞吐能力。

虚拟化还需要留意 NUMA 与内存分配方式。虚拟机可能看到多个 NUMA 节点，也可能被配置为单一节点；虚拟 CPU 与内存若跨节点访问，部分负载的延迟和带宽会发生变化。可查看：

numactl --hardware

若命令不存在，可先安装与发行版匹配的 numactl 软件包，或使用系统提供的 NUMA 工具。测试报告应保留节点信息，不要把不同 NUMA 布局下的结果直接当作同一条件比较。

内存测试还应覆盖容量压力，而不仅是短时带宽。可以在测试环境中逐步提高应用工作集，观察可用内存、交换活动、请求延迟和错误率的变化。不要为追求压力而让生产业务进入持续交换状态；容量测试应在可控的测试虚拟机内进行，并预留足够空间，避免影响系统服务。

四、I/O：不要只看顺序读写速度

虚拟机磁盘性能会受到虚拟磁盘控制器、缓存模式、宿主机文件系统、存储后端以及并发访问影响。一次大块顺序读写的带宽，不能代表数据库小块随机读写能力；平均延迟也可能掩盖少数请求的长尾等待。

磁盘测试至少应关注：

使用 fio 前，先确认测试文件所在目录，并确保文件写入的是专用测试文件，而不是裸设备、系统分区或业务数据文件。以下示例在 /var/tmp 创建测试文件，进行 4 KiB 随机读测试；路径需要根据实际情况调整，并保证磁盘有足够可用空间。

mkdir -p /var/tmp/fio-test
fio --name=randread \
  --filename=/var/tmp/fio-test/testfile \
  --size=2G \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

该命令会创建或使用指定测试文件，并对其进行读取测试。首次运行前确认文件不是重要数据；测试结束后再按需清理该测试文件。--direct=1 用于减少操作系统页缓存对结果的影响，但不代表绕过了虚拟化层和宿主机存储缓存。虚拟磁盘后端仍可能有缓存，因此报告必须记录测试方式。

随后可对同一测试文件执行写入测试。写入会改变测试文件内容，不应把路径改成业务文件或原始设备：

fio --name=randwrite \
  --filename=/var/tmp/fio-test/testfile \
  --size=2G \
  --rw=randwrite \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

再用较大的块尺寸观察顺序读写，可将 --rw 改为 read 或 write，并把 --bs 调整为 1M。比较时除块大小外，其余参数应尽量一致。iodepth 和 numjobs 会改变并发程度：队列加深后 IOPS 可能上升，但延迟也可能增加。因此，不能只报告“最高 IOPS”，还应说明块大小、读写比例、队列深度、作业数、测试时长和延迟分位数。

测试磁盘时应至少重复 3 轮，并分别记录读、写结果。若结果随运行顺序明显变化，可能存在缓存、后台任务或存储共享争用。对于需要了解稳态性能的场景，可延长测试时间并观察多个时间窗口，而不是只取启动后的短暂峰值。

五、如何解读结果：看联动，不用单一门槛下结论

不同业务对指标的敏感点不同。计算任务更看重持续 CPU 吞吐；缓存和数据处理任务可能受内存带宽与容量影响；数据库和小文件服务通常还要关注随机 I/O 与 P99 延迟。一个数字高，并不意味着所有负载都会更快。

下面的示例只用于说明判断方法，不代表特定服务器实测结果：

一个简化的容量判断方式是：先找出业务要求的吞吐和延迟目标，再逐步提高并发，观察延迟开始持续恶化的点。若某一档负载仍满足目标，下一档开始出现高分位延迟超标或错误率上升，就把前一档作为当前配置的可用参考，而不是把极限跑分当作长期承载能力。对生产环境还应保留余量，因为短时基准测试不包含所有后台工作和突发流量。

参考值只有放在明确条件下才有意义。例如，同一个 I/O 测试中，4 KiB 随机读、队列深度 1 与队列深度 32 的结果不能直接互换；同样，单线程 CPU 结果也不能推导出多租户场景的稳定吞吐。若要横向比较两台虚拟机，应统一 vCPU 数、内存量、磁盘测试文件大小、工具版本、测试时长、并发参数和采样时间，并确认两边都没有运行额外任务。

六、复测条件与结果记录

完整测试报告不必堆满终端输出，但应能让其他人按相同条件复现。建议记录：

1. 测试日期与时段、操作系统和内核版本、测试工具版本。
2. 系统可见的 CPU 信息、vCPU 数、内存量、磁盘与文件系统。
3. 每个基准的参数、预热时间、正式测试时长、重复次数。
4. 每轮吞吐、延迟分位数、CPU 利用率、steal time、交换活动和磁盘状态。
5. 是否有其他负载，以及异常轮次是否剔除和剔除依据。

复测时若升级了内核、调整了虚拟机 vCPU 或内存、改变了磁盘缓存模式，或测试期间宿主机负载明显不同，都应视为新的测试条件，不宜与旧数据直接拼接。若结果与预期不符，可先回到单变量测试：CPU 测试期间确认内存和磁盘没有成为限制；内存测试期间避免交换；磁盘测试期间固定文件与队列参数；随后再运行接近业务形态的并发测试。

最终判断应落在具体工作负载上：目标吞吐是否达到要求、P95/P99 延迟是否可接受、峰值并发时是否仍有余量，以及重复测试能否得到相近结果。只有这些条件同时明确，CPU、内存和 I/O 的基准数字才足以支持虚拟化容量评估。