如何评估香港服务器NVMe PCIe Gen4 SSD在数据库负载下的随机IOPS？

仅看到“NVMe PCIe Gen4”和“数十万随机 IOPS”，还不能判断香港服务器是否适合数据库。数据库真正关心的通常不是存储设备在高队列深度下的峰值，而是低队列深度、混合读写和同步提交时的延迟分布，以及这些指标能否稳定支撑目标 TPS、并发数和业务响应时间。

评估时应把测试拆成两层：第一层测试服务器本地 NVMe 的随机 I/O 能力，确认 PCIe 链路、文件系统和设备没有明显瓶颈；第二层在与生产接近的数据库数据集、缓存、事务和连接数下验证 TPS、SQL 延迟、WAL/Redo 刷盘延迟及 CPU、内存、网络等资源。香港机房的网络时延还需要单独测量，不能把远程访问数据库的 RTT 直接归因于 SSD。

面向数据库、业务后台和接口服务，A5数据提供香港物理服务器租用资源，涵盖Xeon Gold、AMD EPYC等平台，并配备SSD或NVMe存储及不同内存组合，为数据库缓存、日志写入和多任务运行提供硬件基础。同时，香港产品提供CN2与国际带宽选项，可结合业务访问区域与网络路径构建相应的服务器部署方案。

一、先明确随机 IOPS在数据库中的含义

IOPS 是每秒完成的 I/O 操作数量，但一个 I/O 操作的大小并不固定。4 KiB 随机读达到 100,000 IOPS，与 16 KiB 随机读达到 100,000 IOPS，对带宽、队列和设备压力并不相同。

计算吞吐量时，可以使用以下关系：

吞吐量 = IOPS × 单次 I/O 大小

例如，80,000 次/秒的 8 KiB 随机 I/O：

• 8 KiB 按二进制口径计算为 8,192 字节；
• 80,000 × 8,192 = 655,360,000 字节/秒；
• 按十进制换算约为 0.655 GB/s；
• 按二进制换算约为 625 MiB/s。

数据库页面大小、日志写入方式和文件系统行为不同，测试中的 bs 不能随意设为 4 KiB 后套用到所有数据库。

PCIe Gen4 代表主机与 NVMe 控制器之间的接口代际，不能直接等同于数据库随机 IOPS。实际结果还会受到 SSD 控制器、闪存颗粒、缓存策略、固件、温度、容量占用、CPU、内存和虚拟化层影响。

二、测试目标应拆成三个问题

一个可执行的评测不应只回答“这块盘有多少 IOPS”，而应分别回答以下问题。

1. 设备本身能否稳定达到预期能力

需要确认：

• NVMe 是否运行在预期的 PCIe Gen4 链路和通道宽度；
• 设备是否为本地直连盘、硬件 RAID 盘或虚拟块存储；
• 随机读、随机写和混合读写在不同队列深度下如何变化；
• 性能峰值能否持续，而不是只在十几秒内出现；
• p99、p99.9 延迟是否在高负载时明显恶化。

2. 数据库真实工作负载是否受益

需要观察：

• 目标并发数下的 TPS 或 QPS；
• SQL、事务提交和连接响应的 p95、p99 延迟；
• 数据库缓冲池命中率；
• WAL、Redo、Binlog 刷盘等待；
• 数据库进程的 CPU、内存和 I/O 等待；
• Checkpoint、锁等待和后台刷脏对前台请求的影响。

3. 余量是否足够支撑业务峰值

评估结果最终要落到容量判断：

• 高峰期读写 IOPS 各是多少；
• 单次 I/O 大小和读写比例是否与测试一致；
• 多个数据库实例是否共享同一块盘；
• 高峰期是否还有 20%～30% 以上的资源余量；
• 容量增加、数据集变大或 SSD 接近满盘后，延迟是否仍可接受。

这里的余量比例只能作为初步运营参考，不能替代业务 SLO。对同步写入敏感的交易库，即使 IOPS 还有余量，只要写入 p99 超出提交时延要求，也不能视为合格。

三、需要同时记录哪些指标

IOPS、吞吐与延迟

随机 IOPS 适合衡量单位时间内的操作数量，吞吐量适合衡量传输的数据量，延迟则反映每一次请求等待了多久。三者必须一起查看。

平均延迟容易掩盖少量慢请求。例如 99%的请求在 0.2 毫秒完成，但1%的请求达到 20 毫秒，平均值可能仍然不高，数据库用户却会明显感受到偶发卡顿。因此至少记录：

• 平均延迟；
• 中位数或 p50；
• p95；
• p99；
• 条件允许时记录 p99.9；
• 最大延迟和长尾出现的时间点。

高峰期可以使用 1 秒粒度的时间序列，而不是只保留一条五分钟平均值。这样才能看出温度上升、Checkpoint、批量任务或其他租户活动引发的瞬时抖动。

队列深度和并发数

队列深度表示设备同时等待处理的 I/O 数量，数据库连接数则表示业务层面的并发。两者不是同一个概念。

在简化条件下，可以用下面的关系理解队列深度：

IOPS ≈ 队列深度 ÷ 平均延迟（秒）

例如队列深度为 32，平均延迟为 0.15 毫秒：

• 0.15 毫秒 = 0.00015 秒；
• 32 ÷ 0.00015 ≈ 213,333 IOPS。

这只是近似关系。实际测试还会受到 I/O 合并、线程调度、CPU 消耗和设备内部并行度影响，但它能说明一个常见现象：高队列深度下的峰值 IOPS，不代表单个数据库事务在低队列深度下也能获得同样的性能。

OLTP 业务通常更关心 QD1、QD4、QD8 或 QD16 下的延迟；批处理、分析查询和大量并行扫描则可能能够利用更高的队列深度。

CPU、内存和 I/O 等待

NVMe 性能上升后，瓶颈可能从存储转移到 CPU 或数据库锁竞争。建议同时记录：

• 用户态 CPU 和内核态 CPU；
• %iowait；
• 系统负载和运行队列；
• 数据库进程 CPU；
• 缓冲池大小和命中率；
• 内存回收、Swap 或 major page fault；
• 文件系统和块设备利用率；
• 中断、软中断和上下文切换。

如果存储 IOPS 已经很高，但 CPU 长时间接近饱和，继续升级 SSD 未必能带来相同幅度的 TPS 提升。反过来，如果 CPU 使用率不高、I/O 等待明显、缓冲池命中率较低，存储延迟通常更值得优先分析。

四、影响香港服务器随机 IOPS的变量

1. PCIe 链路和设备交付方式

首先要确认服务器实际看到的硬件，而不是只依据产品页面中的“PCIe Gen4 SSD”描述。需要核对：

• NVMe 型号和固件版本；
• PCIe 代际与通道宽度；
• 是否存在硬件 RAID、软件 RAID 或虚拟化抽象层；
• 是否为专用本地盘，还是多租户共享块存储；
• 数据盘和日志盘是否共用同一设备；
• 主机是否启用了设备级缓存或写回策略。

Linux 环境下可以先执行只读的识别命令：

lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TYPE,MOUNTPOINT
nvme list
lspci | grep -i -E 'non-volatile|nvme'

如果需要查看链路协商信息，可进一步执行：

lspci -vv

输出中的 LnkCap 是设备支持能力，LnkSta 才是当前协商状态。不能只看到设备支持 Gen4，就认定当前已经以 Gen4 x4 运行。

2. SSD容量占用、温度与持续负载

NVMe SSD 在空盘、半满和接近业务实际占用时，性能可能不同。垃圾回收、磨损均衡和预留空间会影响写入延迟。

测试时应记录：

• 测试前后的已用容量；
• 设备温度；
• 是否出现温控降速；
• 测试持续时间；
• 设备健康度和介质错误；
• 业务数据、日志、临时文件是否位于同一卷。

nvme smart-log 可以用于查看健康和温度信息，但不同设备提供的字段并不完全一致：

sudo nvme smart-log /dev/nvme0

该命令是读取信息，不应替代供应商的健康检查。若设备在测试中出现介质错误、温度告警或健康度异常，应先处理硬件与交付问题，再讨论 IOPS。

3. 文件系统、调度器和数据库参数

直接 I/O 测试与数据库实际访问路径可能不同。需要保持以下条件一致：

• 文件系统类型；
• 挂载参数；
• I/O 调度器；
• 数据库版本；
• 数据库页面大小；
• 缓冲池或共享内存；
• fsync、持久化和提交策略；
• WAL、Redo、Binlog 的位置；
• 数据库是否启用了压缩或透明加密。

如果只用 direct=1 的 fio 测试，通常不会完整模拟数据库日志提交、文件系统元数据和组提交行为。反过来，如果只在数据库热缓存状态下测试，可能几乎没有产生足够的磁盘读请求，也就无法评价随机读能力。

4. 香港机房的网络路径

存储设备的本地测试不包含网络延迟。若应用服务器与数据库服务器不在同一台香港服务器上，事务响应时间至少还包括：

• 应用到数据库的网络 RTT；
• 数据库处理时间；
• 锁等待；
• WAL 或 Redo 刷盘；
• 返回结果的网络时间。

因此，应用部署在同一香港机房、跨机房访问，或从其他地区访问香港数据库，都应使用实际业务路径单独测量。对数据库主机执行的 fio 结果，不能直接作为远程 SQL 响应时间的结论。

五、建议采用两阶段测试

第一阶段：本地块设备基准测试

本地测试的目标是建立设备能力曲线，而不是直接模拟完整业务。建议至少覆盖以下矩阵：

fio 测试会实际产生读写压力。测试文件应放在独立测试卷或隔离服务器上，提前确认有足够空间并完成必要备份，不要直接对生产数据库文件、生产挂载点或包含重要数据的设备执行覆盖性测试。测试结束后应删除测试文件或回收测试卷，避免残留文件占用空间。

下面是一个用于说明测试口径的示例命令，适用于 Linux 上的独立测试路径。命令中的数值需要根据磁盘容量和业务场景调整：

fio --name=db-randrw-8k \
  --filename=/mnt/nvme-test/fio.data \
  --size=64G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=8k \
  --ioengine=libaio \
  --direct=1 \
  --iodepth=8 \
  --numjobs=1 \
  --time_based \
  --runtime=300 \
  --ramp_time=60 \
  --group_reporting

这个示例的总在途 I/O 约为 8。若同时设置 iodepth=8 和 numjobs=4，总并发可能接近 32，不能再把结果称为单队列深度 8 的结果。每次测试应只改变一个主要变量，并将实际参数写入测试记录。

同步写可以单独设计，但要明确它不是数据库 WAL 的完整复刻。例如使用 fdatasync=1 会让每次写入都触发数据同步，可能比数据库组提交更严格；不启用同步，又可能高估掉电保护场景下的表现。更稳妥的方式是将同步 I/O作为压力边界测试，再用数据库自身的提交指标进行验证。

第二阶段：数据库引擎测试

数据库测试应使用与生产相同的引擎和主要版本。PostgreSQL 可以使用 pgbench 或业务回放，MySQL、MariaDB 等可以使用与其事务模型匹配的基准工具或脱敏业务流量。

重点不是工具名称，而是以下条件是否一致：

• 数据集大小；
• 表、索引和分区结构；
• 缓冲池或共享内存；
• 连接数和并发模型；
• 事务大小；
• 读写比例；
• 提交频率；
• 是否启用持久化；
• 数据目录与日志目录的位置；
• 热缓存和冷缓存状态。

数据库测试至少分为预热阶段和稳定采样阶段。预热阶段用于让连接池、缓存和后台线程进入正常状态；稳定阶段再采集 TPS、延迟和系统指标。可以将预热设置为 10～15 分钟，稳定采样设置为 30～60 分钟，并重复三次以上。这里的时间是便于建立基线的参考，不是所有业务都必须采用的固定值。

如果数据集小于内存，测试结果可能主要反映内存和数据库缓存，而不是 SSD。此时应同时保留两组结果：

• 热缓存结果：反映常驻内存时的业务表现；
• 磁盘敏感结果：让工作集明显大于有效缓存，观察磁盘访问时的表现。

不要在生产机上通过清空系统缓存来制造“冷启动”场景。更安全的做法是使用独立测试实例、独立数据目录或重新准备测试环境，并记录数据集、内存和缓存状态。

六、如何采样和组织结果

建议将 fio、数据库和系统监控使用同一时间基准。系统层面可以用以下只读监控命令辅助采样：

iostat -x 1
vmstat 1
pidstat -dru 1
mpstat -P ALL 1

需要关注的不只是设备的 util，还包括：

• 设备平均请求大小；
• await 或类似的设备等待时间；
• 读写请求数量；
• 队列长度；
• CPU iowait；
• 数据库进程的读写速率；
• 业务 TPS 和 SQL 延迟是否同步波动。

结果记录应包含测试环境和时间，而不是只保存一个 IOPS 数字。至少记录：

• 服务器规格、CPU 型号和内存；
• NVMe 型号、固件、链路状态；
• 文件系统和挂载参数；
• 测试数据大小、已用容量和温度；
• 块大小、读写比例、队列深度、并发数；
• 测试持续时间和预热时间；
• IOPS、吞吐量、p50、p95、p99；
• CPU、内存、iowait 和设备利用率；
• 数据库 TPS、事务延迟、日志刷盘延迟；
• 是否有其他任务或共享盘活动。

七、如何解释一组看似漂亮的结果

以下数据只是说明记录方式的示例，不代表某一款香港服务器或某一批 SSD 的实测结果。

这组示例有几个值得注意的地方：

1. QD64 的 IOPS 高于 QD32，并不代表它更适合所有数据库。若业务在 QD16 时已经满足 TPS，而 QD64 让 p99 延迟显著增加，就没有必要为了峰值 IOPS 强行提高并发。
2. QD1 的结果更接近单个同步请求的基础能力。数据库通常由多个连接共同产生 I/O，但事务提交和锁等待仍可能受到低并发延迟影响。
3. 如果平均延迟平稳，p99 却从 0.75 毫秒升至 1.90 毫秒，应继续检查温度、CPU、共享主机活动、垃圾回收和设备缓存，而不能只看 IOPS。
4. 如果 IOPS 在 QD32 以后几乎不再增加，同时延迟持续升高，通常说明设备、主机或软件栈接近饱和。

常见结果组合及判断方向

数据库场景尤其要防止“块设备 IOPS 与业务操作数直接相等”的误判。一次 SQL 事务可能命中缓存、读取多个页面、产生日志并触发同步提交；一个业务请求也可能包含多条 SQL。应当同时记录数据库自身的逻辑读写、物理读写和事务延迟。

八、不同数据库负载应采用不同的判断口径

在线事务型数据库

在线订单、账户、后台管理和高频写入业务，通常更看重：

• QD1～QD16 下的随机读写延迟；
• 4 KiB、8 KiB 或数据库实际页面大小；
• 70/30、80/20 等混合读写；
• WAL、Redo、Binlog 的同步提交延迟；
• p95、p99 和事务回滚率；
• 高并发下的锁等待和 CPU 使用率。

对这类业务，不能用高队列深度下的纯随机读 IOPS作为唯一选型依据。

分析、报表和批处理

分析型业务可能拥有更多并发扫描、临时表和排序溢写，应增加：

• 较大块大小的顺序读写；
• 混合随机与顺序访问；
• 高队列深度下的持续吞吐；
• 多任务同时运行时的在线业务干扰；
• 临时空间使用率和 Checkpoint 影响。

如果报表和在线交易共用一块盘，应测试两者同时运行，而不是分别测试后简单相加。

日志、复制和写密集型业务

写密集型数据库需要增加对以下项目的验证：

• 持续随机写能力；
• 同步写和组提交延迟；
• 写入放大；
• 设备耐久度和健康状态；
• 日志盘与数据盘分离后的变化；
• 长时间运行后的 p99 延迟。

短时间突发写入得到的结果，不能直接替代数小时甚至更长时间的持续写入观察。

九、容量和选型的决策边界

用实际峰值计算需求

先从数据库监控中取得业务高峰期的读 IOPS、写 IOPS、平均 I/O 大小和 p99 延迟。多个数据库实例共享同一存储时，应先汇总实际物理 I/O，再按共享环境重新测试。

例如，高峰期需要 80,000 次/秒的 8 KiB 物理 I/O，理论数据传输量约为 0.655 GB/s。但这个结果只说明带宽需求，不说明 SSD 一定能以可接受延迟完成这些操作。还需要确认：

• 读写比例相同；
• 块大小相同；
• 队列深度接近实际；
• 测试数据占用比例接近业务；
• 同步写比例相同；
• 设备在持续负载下没有明显降速。

比较容量时，建议采用“稳定平台值”而不是最大瞬时值。若某设备在目标混合负载下长期稳定在 200,000 IOPS，而业务峰值为 80,000 IOPS，理论上约使用了平台能力的 40%。如果业务峰值已经达到 160,000 IOPS，即使峰值测试显示 220,000 IOPS，也应谨慎评估，因为尾延迟和后台任务可能使实际可用能力进一步下降。

将稳定平台值的 60%～70%作为常态运行参考区间，是一种便于规划的经验方法，但不适合作为所有数据库的硬性标准。同步事务、延迟敏感型业务和共享存储应采用更保守的余量，并以 p99 延迟和业务 SLO作为最终限制。

交付验收不只验收一个数字

香港服务器交付或更换存储时，可以按以下维度建立验收表：

如果服务商无法提供准确的 SSD 型号或底层共享存储信息，应把验收重点放在可重复的行为指标上，并要求明确性能适用条件。更换主机、迁移宿主机、替换 SSD、升级固件或改变 RAID 配置后，原有测试结果都不能自动沿用。

十、复测条件与容量判断方法

以下情况出现时，应重新进行随机 IOPS 和数据库负载测试：

• NVMe 型号、固件或批次发生变化；
• PCIe 链路从 Gen4 降为其他代际或通道数变化；
• 数据库版本、文件系统或挂载参数变化；
• 内存、缓冲池或连接数明显调整；
• 数据集规模增长，已用容量跨过原测试区间；
• 数据库日志与数据目录合并或拆分；
• 应用与数据库的网络位置发生变化；
• 业务读写比例、事务大小或提交策略发生变化；
• 服务器迁移到不同宿主机或共享资源环境；
• 长时间运行中出现温度告警、p99升高或 I/O 错误。

一套可复用的容量判断流程是：先采集业务高峰期物理读写 IOPS和I/O大小，再在相同读写比例、块大小、并发和同步策略下测试；随后把数据库 TPS、事务 p99、设备 p99、CPU和内存曲线放在同一时间轴比较；最后按数据增长、日志增长和高峰并发增长重新计算余量。只有当本地存储指标、数据库事务指标和远程应用响应同时满足要求时，香港服务器上的 NVMe PCIe Gen4 SSD 才能被视为适合该数据库负载，而不是仅凭一个随机 IOPS 峰值作出判断。