香港NVMe RAID服务器数据库读写IOPS达到30万需要满足哪些测试条件？

要判断香港NVMe RAID服务器的数据库读写IOPS是否达到30万，不能只看测试工具输出的一个峰值数字。必须同时固定块大小、读写比例、队列深度、并发数、RAID模式、数据库持久化策略和测试时长，并确认这个30万是“读写总IOPS”，还是“读取和写入分别达到30万IOPS”。

一组具备参考价值的测试条件通常包括：4K随机混合读写、明确的读写比例、稳定运行至少10分钟、记录P50/P95/P99延迟、数据库开启正常的同步刷盘机制、测试数据集能够持续触发存储访问，并且连续多轮结果接近。若只在短时间突发、关闭fsync或使用不具备掉电保护的写回缓存，得到的30万IOPS不能直接解释为数据库可持续的性能。

先定义“30万IOPS”到底代表什么

一份合格的香港NVMe RAID服务器深度测评，需要先把测试对象分成三层，否则很容易把不同含义的数字放在一起比较。

IOPS是每秒完成的I/O操作数，通常可以用“完成的操作数量 ÷ 测试秒数”计算。它必须和块大小一起阅读：

• 300,000 IOPS、4K块，大约对应1.23 GB/s的十进制数据吞吐，约为1.17 GiB/s。
• 300,000 IOPS、16K块，大约对应4.92 GB/s的十进制数据吞吐。
• 如果是70%读取、30%写入，且总IOPS为300,000，那么大致对应210,000读取IOPS和90,000写入IOPS，并不代表读写各自都达到30万。
• 如果要求读取和写入分别达到30万IOPS，混合总量就接近60万IOPS，测试难度和带宽需求会明显不同。

因此，报告中不能只写“IOPS：300,000”，而应写成类似下面的完整口径：

4K随机混合读写，读写比例70/30，8个并发任务、每个任务队列深度32，总队列深度最多256，直接I/O，稳定运行10分钟，读写合计IOPS达到约30万，P99设备延迟不超过指定阈值。

这类描述才具备复测价值。

测试目标：区分存储峰值与数据库真实表现

测试前需要先确定想回答哪一个问题。

如果目标是确认阵列的存储上限，可以先进行块设备测试。此时关注4K随机读、4K随机写和4K随机混合读写，用于观察NVMe、RAID层、文件系统和内核I/O路径的综合表现。

如果目标是确认数据库能否达到30万读写IOPS，则必须把数据库引擎、数据页、日志、事务提交和同步刷盘纳入测试。数据库的物理I/O不一定等于SQL数量，也不一定等于事务数量：

• 一条查询可能命中内存，只产生逻辑读，不产生物理磁盘读。
• 一次事务可能修改多个数据页，并额外产生WAL、Redo或Binlog写入。
• 多个事务可能通过组提交合并刷盘，SQL吞吐和底层写IOPS会发生变化。
• 数据库缓冲池过大时，测试结果可能主要反映内存，而不是NVMe RAID阵列。

所以，块存储测试达到30万IOPS，只能说明“阵列在某个I/O模型下具备这一访问能力”；数据库测试也达到30万物理读写IOPS，才能说明“在指定数据库负载下出现了这一存储访问量”。

测试环境必须完整记录

服务器和RAID参数

测试报告至少应记录以下内容：

NVMe数量并不能单独代表阵列性能。需要确认每块设备是否都获得了足够的PCIe通道，RAID控制器或软件RAID是否成为瓶颈，条带大小是否适合数据库页和日志写入。

不同RAID级别也不能直接横向套用结论。镜像类阵列通常更容易获得稳定的随机写延迟；带校验的阵列在小块随机写时可能产生额外的读改写和校验开销。测试报告如果没有写明RAID级别，就无法解释写IOPS低于读IOPS的原因。

尤其需要核对写缓存策略。如果控制器或固态设备使用了没有掉电保护的写回缓存，短时写入结果可能很高，但断电时尚未落盘的数据存在丢失风险。数据库开启同步提交时，测试应以可持久化的写入结果为准，而不是单纯采用缓存确认速度。

数据库和文件布局

需要明确：

• 数据库引擎及版本；
• 数据文件、日志文件、临时文件是否位于同一组NVMe RAID；
• 数据库页大小；
• 缓冲池或共享内存大小；
• 是否开启二进制日志、WAL或Redo日志；
• 检查点、日志刷新和同步提交策略；
• 是否使用直接I/O；
• 数据集大小、索引大小和数据分布；
• 测试数据是否大于数据库可用缓存。

建议至少准备两种场景：

1. 存储受限场景：数据文件和索引总量明显大于数据库缓存，让随机访问更多地落到NVMe阵列。
2. 缓存命中场景：数据集能够大部分放入内存，用于观察数据库缓存对SQL延迟和逻辑读的影响。

两种场景都有效，但不能混为一个“数据库IOPS”结论。缓存命中场景更适合评估查询响应和CPU处理能力，存储受限场景更适合评估阵列对物理读写的承载能力。

测试客户端和运行状态

数据库测试的客户端位置也要固定。若客户端通过网络访问数据库，事务响应时间中会包含网络传输和连接处理耗时；若要单独观察存储，应优先使用服务器本机连接或固定的低变量测试客户端，同时单独记录网络因素。

测试期间应关闭无关的备份、批量导入、日志压缩和系统扫描任务，并记录：

• 服务器是否存在其他高负载进程；
• CPU利用率和I/O等待；
• 内存回收、交换分区使用情况；
• NVMe温度和降速；
• RAID重建、校验或后台巡检状态；
• 磁盘剩余空间和使用比例。

需要采集的核心指标

IOPS、带宽和读写比例

IOPS要同时拆分为读取IOPS、写入IOPS和读写总IOPS。单独列出总量会掩盖读写不平衡。

带宽用于检查IOPS是否符合块大小计算。以4K混合读写为例，如果总IOPS从30万提升到60万，带宽也会接近翻倍；但如果把块大小从4K改为16K，即使IOPS不变，带宽也会增加约4倍。

读写比例则决定结果是否贴近业务。如果业务以读取为主，70/30的测试可能会低估读取能力；如果业务包含大量同步小块写入，纯读取测试又会明显高估实际表现。

延迟分位数

平均延迟不能代表高并发业务体验，应至少记录：

• P50：一半请求的延迟低于该值；
• P95：较常见的尾部延迟；
• P99：高并发下更有参考价值的尾部延迟；
• P99.9：对严格低延迟业务尤其重要。

如果IOPS达到30万，但P99延迟已经从1毫秒升到20毫秒，说明阵列可能是在排队中换取吞吐。这样的结果可以称为“高并发峰值IOPS”，但不一定适合对延迟敏感的数据库。

在稳态并发下，可以用一个简单关系辅助判断：

并发中的I/O数量约等于IOPS乘以平均延迟。

例如，总队列深度约为256、IOPS约为300,000时，理论平均等待时间约为256 ÷ 300,000秒，即0.853毫秒。实际结果还会受到调度、RAID处理、数据库排队和测量方式影响，但如果报告中显示队列深度只有几十，却声称300万级低延迟IOPS，就需要进一步核对测试口径。

并发、队列和资源利用率

应记录每个测试任务的并发数、每个任务的队列深度，以及总队列深度。不能只写“QD32”，因为8个任务、每个QD32，与1个任务、QD32的实际压力并不相同。

同时采集：

• CPU总利用率、系统态和用户态占比；
• I/O等待比例；
• 内存使用和缓存命中；
• 设备利用率；
• 设备读写等待时间；
• 数据库锁等待和日志等待；
• 提交延迟、检查点压力和后台刷脏页速度。

如果CPU已经接近饱和，而设备利用率并不高，结果更可能是数据库处理或测试工具受到CPU限制。如果I/O等待持续升高、设备队列变长、P99延迟明显上升，则更接近存储阵列达到瓶颈。

推荐的测试流程

第一步：确认设备和系统状态

Linux环境下，可以先记录块设备、NVMe设备和实时I/O状态：

sudo lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINTS
sudo nvme list
sudo iostat -xmd 1

nvme list需要系统已安装相应工具；如果命令不可用，应记录工具版本或使用操作系统提供的设备信息，不要用猜测值替代。iostat用于观察设备利用率、读写吞吐、队列和等待时间，采样间隔建议固定为1秒。

这一步不改变数据，只用于建立环境基线。若需要检查温度、固件或RAID缓存策略，也应先完成记录，再开始压测。

第二步：进行块存储基线测试

块存储测试应使用专用测试文件或专用测试卷，不能直接把数据库数据文件作为测试目标。下面是一个4K随机混合读写的示例，数值仅用于说明测试口径：

mkdir -p /data/bench

fio --name=db-randrw-4k \
  --filename=/data/bench/fio.test \
  --size=100G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=32 \
  --numjobs=8 \
  --time_based=1 \
  --runtime=600 \
  --ramp_time=120 \
  --group_reporting=1 \
  --output=/data/bench/db-randrw-4k.txt

执行前要确认/data/bench/fio.test是专用测试文件。若该文件已经存在，测试可能覆盖其中内容；不要把--filename指向数据库数据目录、日志文件或其他生产文件。

这个示例的含义是：

• 4K随机访问；
• 70%读取、30%写入；
• 8个任务，每个任务队列深度32；
• 总队列深度上限约为256；
• 使用直接I/O，尽量减少操作系统页缓存影响；
• 预热120秒，稳态运行600秒。

实际测试不应只跑一个队列深度。建议至少测试QD1、QD4、QD8、QD16、QD32、QD64和QD128，并保持任务数、块大小和读写比例的记录方式一致。低队列深度更接近单请求延迟，高队列深度用于观察阵列吞吐上限。

还应分别测试：

• 4K随机读取；
• 4K随机写入；
• 4K随机70/30混合读写；
• 与业务实际比例一致的混合读写。

如果测试文件小于服务器内存，或者没有使用直接I/O，读取结果可能主要来自内存缓存。用于存储能力比较时，应保证测试文件和访问范围足够大；如果使用缓存命中场景，则应明确标注为缓存测试。

第三步：进行数据库真实负载测试

数据库测试不能用fio结果替代。应使用与目标数据库匹配的基准工具或业务回放工具，至少设置只读、只写和混合读写三类负载。

混合读写测试中，需要固定：

• 事务模型；
• 读写比例；
• 查询是否使用预编译或预处理；
• 每个事务包含的SQL数量；
• 提交频率；
• 并发连接数；
• 数据表和索引规模；
• 数据访问分布；
• 是否开启同步提交和日志落盘。

数据库的持久化设置应接近生产使用方式。例如，关系型数据库测试不能为了提高数字而关闭正常的fsync、同步提交、Redo或WAL刷新。MySQL类环境需要记录Redo刷新和Binlog同步策略；PostgreSQL类环境需要记录fsync和同步提交策略。不同配置会改变写入确认时机，必须在报告中明确。

每个并发档位建议按以下过程执行：

1. 清理或记录上一个场景的状态，确认测试数据完整。
2. 预热2至5分钟，让连接池、缓存和后台线程进入稳定状态。
3. 稳态采样至少10分钟。
4. 同步采集数据库统计、操作系统I/O和设备延迟。
5. 停止测试后记录检查点、日志积压、错误和超时。
6. 在相同条件下重复至少3轮。

并发数可以从1、2、4、8、16、32逐步增加，直到吞吐趋于平稳或P99延迟明显恶化。不能只选择一个很高的并发数来制造峰值，因为那样无法判断30万IOPS是否处于可用区间。

第四步：同步采集数据库与系统数据

数据库内部至少应记录：

• TPS或QPS；
• 事务提交和回滚；
• 逻辑读、物理读；
• 数据页写入；
• 日志写入量；
• 日志刷新次数和平均刷新延迟；
• 检查点写入；
• 缓冲池命中率；
• 锁等待和连接等待。

操作系统层面则要同步记录：

• 块设备读写IOPS；
• 设备读写带宽；
• await或等效设备等待时间；
• 设备队列长度；
• CPU用户态、系统态和I/O等待；
• 内存和交换分区；
• NVMe温度与降速状态。

这样才能判断数据库报告的“物理读写”是否真的落到了NVMe RAID，而不是停留在缓冲池、文件系统缓存或控制器易失缓存中。

示例结果应该怎样解释

下面数据是用于说明判读方法的示例，不代表任何具体服务器的实测结果。

第一个场景只能证明块存储层在特定条件下具备相应能力。第二个场景更接近数据库存储层，但是否合格仍需结合业务对P99延迟、错误率和持续时间的要求。第三个场景说明逻辑读和物理读不能混用。第四个场景则说明关闭持久化选项后得到的写入结果不具备同等的可靠性含义。

常见的结果差异可以这样分析：

fio高、数据库IOPS低

可能原因包括：

• 数据库页大小与fio块大小不同；
• 数据库增加了日志、校验和事务管理开销；
• 同步提交导致写入等待；
• 缓冲池策略改变了物理访问比例；
• SQL执行或锁竞争先达到瓶颈；
• RAID写放大在数据库负载中更加明显。

这种结果不代表测试失败，而是说明块设备峰值不能直接转化为数据库吞吐。需要继续查看CPU、锁等待、日志刷新和物理I/O统计。

读取高、写入明显低

可能与以下因素有关：

• RAID校验写入带来读改写；
• 写入采用同步提交；
• 控制器处于直写模式；
• 日志文件和数据文件争用同一组设备；
• 数据库后台刷脏页无法及时追上前台事务；
• NVMe温度升高后发生降速。

如果读取IOPS很高而写入P99延迟突然升高，应优先查看设备队列、日志刷新延迟和RAID缓存状态，而不是简单提高并发数。

IOPS继续上升，但P99延迟快速恶化

这通常说明系统已经进入排队换吞吐阶段。可以把不同队列深度的结果画成曲线：当IOPS增幅变小、P99延迟成倍增加时，曲线拐点就是比较有价值的容量边界。

例如，QD32时达到250,000 IOPS、P99为2毫秒；QD64时达到305,000 IOPS、P99升到9毫秒。若业务要求P99不超过5毫秒，那么30万IOPS虽然在数值上达到目标，却不应被判定为满足该业务条件。

设备利用率不高，但数据库延迟很高

此时瓶颈可能在CPU、锁、连接、日志提交或数据库执行层，而不是NVMe设备。也可能是I/O请求数量本身不够，数据库没有把阵列压满。

相反，如果CPU利用率不高、I/O等待增加、设备队列持续增长，同时P99升高，则更接近存储子系统达到极限。

达到30万的验收口径应怎样写

如果要把“达到30万”作为测试结论，建议至少包含以下条件：

严格验收时，可以要求每一轮有效测试都达到目标，而不是只取最高值。工程评估时，也可以使用多轮中位数，并把最低值、最高值和P99延迟一并展示。无论采用哪种方式，都要提前写清楚，不能测试结束后再选择最有利的统计口径。

对于实际业务容量，不建议把生产峰值刚好压在30万IOPS。若业务峰值估算为240,000物理IOPS，可把30万作为约25%的参考余量，但还要验证读写比例、延迟和增长后的数据集规模。容量判断不能只按“峰值IOPS ÷ 目标IOPS”计算，还要考虑日志写放大、后台刷盘、检查点和高峰期间的P99延迟。

哪些变化必须重新测试

以下任一项发生变化，都不应直接沿用原来的30万结论：

• NVMe数量、型号、固件或RAID级别变化；
• RAID条带大小或缓存策略变化；
• 文件系统、挂载方式或I/O调度器变化；
• 数据库版本、页大小或缓存参数变化；
• 日志、数据文件和临时文件的存放位置变化；
• 数据集大小、索引数量或访问分布变化；
• 读写比例、事务大小或并发连接数变化；
• 开启或关闭同步提交、日志同步或直接I/O；
• 服务器容量使用率明显增加；
• NVMe温度、后台巡检、重建或设备健康状态变化；
• 测试客户端位置和连接方式变化。

尤其要注意短时突发与持续性能的差异。测试开始前几分钟可能受设备缓存和控制器写回策略影响，最后几分钟才更能反映稳态。复测时应比较预热阶段、稳态前段和稳态后段，而不是只截取最高的一秒。

因此，香港NVMe RAID服务器数据库读写IOPS突破30万，真正需要满足的不是某个孤立的峰值，而是一套可复现的条件：固定读写模型和并发队列，使用真实数据库持久化策略，在足够大的数据集上持续运行，同时采集物理读写、数据库事务、尾部延迟和系统资源。只有当多轮结果在相同条件下稳定出现，并且P99延迟、错误率和数据持久性也符合业务要求，30万IOPS才具有实际的容量判断价值。