960G NVMe SSD香港服务器百万级随机IOPS如何测试站点读写性能？

“百万级随机 IOPS”通常是存储设备在特定块大小、队列深度和并发线程下得到的峰值，不等于网站每秒能处理百万次请求。要测试 960G NVMe SSD 香港服务器的站点读写性能，应把测试拆成三层：先测 NVMe 存储本身，再测文件系统与同步写入，最后用接近真实网站访问和写入流程的业务负载验证。只有三层结果能够相互对应，才能判断高 IOPS 是否真正转化为较低的页面延迟和更高的并发承载能力。

实际操作时，至少要同时记录 4K 随机读、4K 随机写、混合读写、队列深度、并发数、吞吐量、平均延迟、P95/P99 延迟、CPU、内存、I/O 等待和错误率。测试结果不应只写“达到多少 IOPS”，而要写清测试节点、时间、系统、磁盘使用率、fio 参数、样本时长和业务负载边界。

先明确“百万级随机 IOPS”测的是什么

IOPS与网站请求不是同一个指标

IOPS表示每秒完成的存储操作次数，网站请求则是一次完整的 HTTP 请求、页面渲染或业务事务。一次动态页面请求可能包含：

• 多次读取模板、配置和缓存文件；
• 多条数据库查询；
• 若干随机读和随机写；
• 一次或多次事务提交；
• 日志写入、索引更新或文件落盘。

因此，网站每秒 100 个请求，并不一定只产生 100 IOPS。反过来，存储测试得到 100 万 IOPS，也不代表网站可以处理 100 万次请求。

4K 随机 I/O 的吞吐量可以这样换算：

吞吐量 = IOPS × 每次 I/O 的数据量

以 1,000,000 次/秒、每次 4KiB 为例：

• 1,000,000 × 4,096 字节 = 4,096,000,000 字节/秒；
• 按十进制换算约为 4.096 GB/s；
• 按二进制换算约为 3.814 GiB/s。

这说明百万级 4K IOPS往往需要较高的并发队列。它可能是在较高队列深度下测出的随机读峰值，而普通网站的小并发、低队列请求未必能达到同样的数字。

三层测试口径

存储层测试适合回答“这块盘在给定参数下能做到什么程度”，业务层测试则回答“这个网站在给定访问模式下能稳定处理多少请求”。两者不能相互替代。

测试前要固定环境和边界

需要记录的环境信息

每次测试前先建立一份环境记录。960G 是标称容量，系统实际可用空间还会受到分区、文件系统、预留空间和已有数据影响。磁盘使用率不同，后台垃圾回收和写放大情况也可能不同。

可以先使用以下命令核对基础信息。命令只读取系统状态，不会清理缓存，也不会修改网站数据。

uname -a
lscpu
free -h
df -hT
findmnt -T /srv/bench
fio --version

/srv/bench只是示例测试目录，实际使用前应替换为单独的测试路径，并确认该路径不是网站数据目录、数据库数据目录或日志目录。

生产环境不要直接跑破坏性写入

随机写测试会产生持续 I/O，并可能影响网站响应、数据库提交和日志落盘。安全顺序应当是：

1. 优先使用与生产环境一致的测试服务器或快照恢复出的副本；
2. 如果只能在生产服务器上测试，先完成网站文件和数据库备份；
3. 使用独立测试文件，不要把 fio 指向数据库原始设备；
4. 预留足够磁盘空间，避免测试文件把文件系统写满；
5. 在业务低峰期执行，并提前设定停止条件；
6. 测试结束后确认文件名和目录，只有合成测试文件可以清理；
7. 如果网站延迟、错误率或 I/O 等待明显升高，应立即停止压测并恢复正常业务负载。

在生产盘上直接对原始块设备执行随机写，可能覆盖分区或业务数据。除非已经完成完整备份、明确影响范围并具备重建和回滚条件，否则不应采用这种方式。

存储层测试：不要只跑一次默认参数

先选择与网站相近的工作集

测试文件太小，可能只覆盖很小的地址范围，无法反映实际 SSD 使用状态；测试文件过大，又可能挤压网站缓存和数据库空间。一般可以按以下原则选择：

• 测试文件至少覆盖网站实际活跃数据集；
• 在测试环境中，可以使用可用空间的约 10%至20%作为起始工作集；
• 如果网站数据库和文件总活跃数据已经超过该范围，应以实际活跃数据规模为准；
• 生产环境不要为了测试刻意填满磁盘；
• 记录测试时的磁盘使用率，复测时尽量保持一致。

以 960G 标称容量的服务器为例，64G 测试文件可以作为演示值，但不代表适合所有站点。若实际数据库活跃数据为 150G，仅用 1G 或 4G 文件测试，结果可能过于理想化。

测试矩阵应覆盖这些组合

总队列深度大致等于 iodepth × numjobs。例如 iodepth=32、numjobs=8，总队列约为 256。此时测得的百万级 IOPS，不能直接与 iodepth=1 的网站请求相比较。

使用测试文件时绕开页面缓存

下面的命令用于演示 4K 随机读取。它使用测试目录和合成文件，不应指向网站真实数据。

先准备测试目录，并确认剩余空间足够：

mkdir -p /srv/bench/fio-run-01
df -hT /srv/bench/fio-run-01
findmnt -T /srv/bench/fio-run-01

为了让随机读取有实际数据可读，可以先对合成文件进行预填充。下面示例中 size=8G 是每个作业的文件大小，8 个作业合计约 64G。

fio \
  --name=fill-site-set \
  --directory=/srv/bench/fio-run-01 \
  --filename_format='site-set.$jobnum' \
  --size=8G \
  --rw=write \
  --bs=1M \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=16 \
  --numjobs=8 \
  --group_reporting=1

随后执行 4K 随机读取：

fio \
  --name=randread-4k-qd256 \
  --directory=/srv/bench/fio-run-01 \
  --filename_format='site-set.$jobnum' \
  --size=8G \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=32 \
  --numjobs=8 \
  --runtime=300 \
  --ramp_time=60 \
  --time_based=1 \
  --group_reporting=1 \
  --randrepeat=0 \
  --percentile_list=50:90:95:99:99.9

这里有几个关键参数：

• --direct=1尽量绕开操作系统页面缓存，减少“内存缓存被误认为磁盘性能”的情况；
• --iodepth=32表示每个作业保持较深的请求队列；
• --numjobs=8表示并行运行 8 个作业；
• --runtime=300表示测量阶段持续 300 秒；
• --ramp_time=60用于预热，预热阶段不作为主要统计窗口；
• --percentile_list要求输出多个延迟百分位；
• --group_reporting=1将多个作业合并显示，便于查看总 IOPS。

如果当前系统不支持 libaio，先使用以下命令确认可用 I/O 引擎：

fio --enghelp

再根据系统实际支持情况选择可用引擎，不要直接照搬不兼容的参数。

读、写和混合测试要分开

随机读取只能说明读取能力。网站写入通常涉及事务提交、日志同步和数据持久化，必须单独测试。

随机写可以将上面命令中的关键参数改为：

fio \
  --name=randwrite-4k-q d \
  --directory=/srv/bench/fio-run-01 \
  --filename_format='site-set.$jobnum' \
  --size=8G \
  --rw=randwrite \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=16 \
  --numjobs=8 \
  --runtime=300 \
  --ramp_time=60 \
  --time_based=1 \
  --group_reporting=1 \
  --randrepeat=0 \
  --percentile_list=50:90:95:99:99.9

上面示例中的作业名称出现了空格，实际执行时应使用不含空格的名称，例如：

fio \
  --name=randwrite-4k-qd128 \
  --directory=/srv/bench/fio-run-01 \
  --filename_format='site-set.$jobnum' \
  --size=8G \
  --rw=randwrite \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=16 \
  --numjobs=8 \
  --runtime=300 \
  --ramp_time=60 \
  --time_based=1 \
  --group_reporting=1 \
  --randrepeat=0 \
  --percentile_list=50:90:95:99:99.9

混合读写可以使用 70%读取、30%写入的比例：

fio \
  --name=randrw-4k-70r30w \
  --directory=/srv/bench/fio-run-01 \
  --filename_format='site-set.$jobnum' \
  --size=8G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=16 \
  --numjobs=8 \
  --runtime=300 \
  --ramp_time=60 \
  --time_based=1 \
  --group_reporting=1 \
  --randrepeat=0 \
  --percentile_list=50:90:95:99:99.9

这些命令测试的是异步随机 I/O。若站点写入依赖事务提交，还要增加同步写场景，例如使用 fsync=1 或 fdatasync=1，并将结果单独标注为“同步写延迟”。同步写通常不能用异步随机写的 IOPS 代替。

站点层测试：把真实读写路径单独测出来

读请求至少分为两种状态

网站读取容易受到页面缓存、对象缓存和数据库缓存影响，应分别测试：

1. 热缓存读取：连续访问已经加载到内存中的页面或数据；
2. 较冷缓存读取：使用足够大的数据集和随机访问，减少单纯内存命中的比例。

不能为了得到“冷缓存”结果而在生产环境频繁执行清理系统缓存的命令。清理缓存会影响整台服务器上的其他服务，并不能完全复现真实访问。更稳妥的方式是在隔离测试环境中准备可控数据集，分别记录缓存状态。

写入路径要模拟真实提交

网站写入测试不能只上传一个大文件。更有参考价值的场景包括：

• 新增一条内容或订单记录；
• 修改已有记录并提交事务；
• 写入访问日志或操作日志；
• 更新索引、计数器或状态字段；
• 读写混合的动态页面请求。

如果业务本身要求提交后数据不能丢失，应重点观察同步提交后的请求延迟，而不是只看后台异步写入的吞吐量。

固定请求速率，再逐步增加并发

只把并发数设置得很高，容易制造队列堆积，最后得到的是“极限压垮点”，而不是可用容量。更合理的测试顺序是：

1. 以低请求速率开始，例如 10、20、50、100 RPS；
2. 每个速率保持足够长时间，等待延迟稳定；
3. 记录平均延迟、P95、P99、错误率和服务器资源；
4. 逐步提升并发或目标 RPS；
5. 找到延迟开始持续上升、错误率增加或 I/O 队列明显堆积的拐点；
6. 在拐点以下再次运行较长时间，验证是否能够稳定维持。

压测端的位置和连接路径要固定。远程网络往返时间应单独记录，不能把网络延迟直接归因于 NVMe。存储层测试应在服务器本机执行，业务层测试则要同时记录客户端到服务器的网络耗时。

必须采集的指标及其含义

可以使用以下监控命令观察服务器状态。若系统未安装相应工具，应先确认工具来源和版本，不要在生产环境中临时执行未经验证的安装操作。

iostat -x 1

vmstat 1

pidstat -d 1

重点关注以下组合：

• %util持续接近满载，同时 await和 P99 延迟上升：存储设备或队列可能已经饱和；
• CPU 用户态或内核态接近瓶颈，但磁盘利用率不高：可能是应用逻辑、加密、压缩或连接处理限制；
• wa较高、CPU其他指标不高：线程主要在等待 I/O；
• 平均延迟不高，但 P99 明显升高：尾延迟已经影响部分请求；
• IOPS很高但业务 RPS没有提升：应用层、数据库锁、缓存或网络可能是主要瓶颈。

如何阅读测试结果

先看队列深度，再看峰值 IOPS

下面是一组仅用于说明阅读方法的示例数据，不代表该服务器的实际测试结果：

如果报告只写“随机读接近百万 IOPS”，读者无法知道这个数字来自 QD1 还是 QD256，也不知道是读、写还是混合场景。正确表达应类似于：

在 4K 随机读、8 个并发作业、每个作业队列深度为 32、总队列深度约 256 的条件下，测试输出约为某个 IOPS 区间；该结果不代表低队列网站请求或同步写入能力。

观察是否出现“吞吐增加、延迟失控”

随着队列深度提高，常见变化是：

1. IOPS快速增加；
2. IOPS逐渐趋于平台；
3. 队列继续加深，但 IOPS增长很小；
4. P95、P99延迟开始明显上升。

第 3 和第 4 阶段之间通常就是设备从扩展区进入饱和区的位置。网站的可用容量不应直接取最高 IOPS，而应取延迟仍在业务目标内的工作点。

例如某组测试在 QD64 时为 600,000 IOPS、P99 为 1.8ms，在 QD256 时为 900,000 IOPS、P99 升至 15ms。若网站更看重页面响应，那么 QD64 的工作点可能比 QD256 更有实际价值，即使前者的峰值 IOPS较低。

识别缓存、同步写和长期写入影响

以下情况需要特别复核：

• direct=0远高于direct=1：结果可能主要反映页面缓存，而不是 SSD；
• 短测很快，长测持续下降：可能受到写入放大、垃圾回收、测试文件范围或磁盘使用率影响；
• 异步写很高，同步写很低：网站事务提交可能受持久化延迟限制；
• 读性能很好，混合读写下降明显：写入可能占用队列，影响读取尾延迟；
• 同一参数三次差异很大：可能有后台备份、日志轮转、业务流量或缓存状态变化；
• 单线程结果低，但高并发结果很高：设备更适合并行队列，不能将峰值套用到单请求场景。

每组测试至少保留三次结果。可以用“最大值与最小值的差异相对于中位数的比例”观察波动。如果差异达到约 10%或更高，应先排查后台任务、磁盘空间、温度、缓存状态和并发干扰，再决定是否取平均值。

从存储结果推导站点容量

网站容量估算应从业务操作数开始，而不是从“百万 IOPS”倒推。

例如，一个动态请求平均产生 6 次随机读和 1 次随机写，目标流量为 100 RPS，则理论存储操作量约为：

• 100 × 6 = 600 次随机读/秒；
• 100 × 1 = 100 次随机写/秒；
• 合计约 700 次存储操作/秒。

这只是业务层估算。缓存命中、数据库批量读取、预取、写缓冲和事务合并都会改变实际 I/O 数量，因此应使用监控或应用追踪数据校正。

如果目标是 200 RPS、平均响应时间 150ms，则同时在处理中的请求量大约为：

200 × 0.15 = 30 个并发请求

这并不表示存储队列一定是 30，因为一次请求可能包含多个并行查询，但可以帮助确定业务压测的初始并发范围。

实际决策可以按以下边界进行：

• 低队列随机读延迟稳定，说明单请求访问基础较好；
• 目标 RPS下 P95/P99仍在业务设定范围内，说明用户感知延迟可接受；
• 混合读写时 I/O 队列没有长期堆积，说明读写互相影响有限；
• CPU、内存和数据库等待没有先于磁盘达到瓶颈，说明存储结果具有业务转化空间；
• 达到目标流量后仍保留一定余量，不把饱和点作为日常运行点。

余量应根据业务波动、备份任务和增长速度确定。刚开始规划时，可以把目标工作点放在明显低于延迟拐点的位置，再通过持续监控调整，而不是直接以测试中的最高 IOPS 作为上线容量。

复测时必须保持同一口径

960G NVMe SSD 香港服务器的性能结果会随数据量、空间使用率、测试时长和后台任务变化。以下情况发生后，建议重新测试：

• 网站数据库或文件数据明显增长；
• 磁盘使用率进入新的区间；
• 操作系统、文件系统或内核升级；
• 网站读写比例发生变化；
• 增加备份、日志、索引或批量任务；
• 发现 P99 延迟持续升高；
• 业务并发量接近原测试的拐点；
• 服务器迁移、重装或存储配置发生变化。

复测时应保持以下条件尽量一致：

• 测试文件大小和文件分布；
• 磁盘使用率；
• 块大小、读写比例、队列深度和并发作业数；
• 预热时间和正式采样时间；
• fio与系统版本；
• 测试节点位置和网络路径；
• 网站缓存状态和业务数据规模；
• 服务器上的备份、日志轮转等后台任务。

一份合格的性能记录，不应只有一个“百万级 IOPS”数字，而应包含“测试条件—指标结果—业务表现—限制因素”四部分。对站点读写性能而言，低队列延迟、同步写 P99、混合负载稳定性和目标 RPS下的错误率，通常比脱离业务场景的峰值随机 IOPS更能说明 960G NVMe SSD 香港服务器是否适合当前网站。