NVMe 和 SSD VPS 有什么区别，值得选吗？

VPS 上的 NVMe 是否重要？

当软件需要执行大量小型读写操作，并且每次都要等待操作完成时，NVMe 对 VPS 很重要。对于提供缓存页面的网站，或者大部分时间都在等待网络的程序，NVMe 带来的变化很小。存储介质只是影响因素之一。磁盘前面的虚拟机监控程序，以及共享同一台宿主机的其他虚拟机，决定了您实际能够获得的性能上限。

NVMe 会改变什么，以及不会改变什么

NVMe（非易失性内存快速）不是一种闪存。它是访问闪存时使用的协议和连接方式。NVMe 设备通过 PCIe（外围组件互连快速）通道连接，并使用 NVMe 协议通信。SATA（串行 ATA）SSD 通过 SATA 链路连接，并使用 AHCI（高级主机控制器接口）通信。两者使用的存储数据的内存芯片可能完全相同。

两者有两个差异，而且都涉及命令路径，而不是存储介质本身。

队列。 AHCI 为内核提供一个可容纳 32 个命令的命令队列。NVMe 支持数千个队列，实际使用中通常每个 CPU 核心一个，而且每个队列的深度都远大于 32。一个进程每次只读取一个块时，无法体现这一差异。一个同时发出 64 个读取请求的数据库则可以体现：在 SATA 上，第 33 个请求必须等待队列空出位置，设备甚至还看不到它；NVMe 设备则可以一次接受全部请求并并行处理。

链路宽度。 SATA III 链路的速率为 6 Gbit/s，扣除协议开销后，实际数据速率约为 550 MB/s。无论后端使用哪种闪存，这都是固定上限。4 条 PCIe 通道可提供每秒数 GB 的带宽，因此链路不再成为限制。

延迟通常最容易产生错误预期。在队列深度为 1 时，也就是同时只有一个请求在处理，SATA SSD 完成一次 4k 读取约需 100 到 150 微秒。NVMe 约需 80 到 100 微秒。两者都很快，单个请求的差异不会被实际运行的程序察觉。并发请求增加后，差异才会显现。队列深度，即同时处于处理中的请求数量，决定了两种介质的表现是相近还是差异明显。

网络块存储属于第三类，其工作机制不同。写请求会通过网络发送到存储集群，只有集群持久保存数据后才会确认，因此延迟以毫秒而不是微秒计算。换来的优势是持久性：卷的生命周期不受所连接主机影响，并且可以创建快照和调整大小。

典型公布数据：NVMe、SATA SSD 和网络存储

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

本地 NVMe 设备在队列深度为 32 时，随机 4k 读取 IOPS（每秒输入/输出操作数）通常公布为 184,000。在 SATA SSD 上进行相同测试时，通常约为 90,000，这是因为它受单个 AHCI 队列和 6 Gbit/s 链路限制。网络块存储通常受提供商限制，而不是受硬件限制；12,500 是常见的文档标称上限。

延迟以用户实际感知的单位反映了相同差异。p99 读取延迟是指最慢的 1% 请求，其在本地 NVMe 上约为 0.4 ms，在 SATA 上约为 1.2 ms。将网络加入数据路径后，延迟会升至 6.5 ms，超过 NVMe 数值的十倍。

顺序读取的差距最大，但参考价值最低：3,400 MB/s 对比 550 MB/s。服务器上几乎没有任务会以全速从头到尾读取一个大型文件。随机读取和延迟两列数据，更能反映数据库、邮件队列或包管理器的实际行为。

哪些工作负载会感受到磁盘性能

一个规则可以解释所有情况：只有在等待磁盘时，工作负载才会感受到磁盘性能。Linux 会将最近使用的文件数据保存在 RAM 的页缓存中，因此第二次读取文件时不会访问存储设备。如果工作集，即实际使用中的数据，可以放入 RAM，那么首次读取后，后续读取就会变成内存读取。写入则不同。应用通过 fsync() 刷新数据时，数据必须先写入持久存储，应用才能继续执行。

会提交事务的工作。 PostgreSQL、MySQL 和 SQLite 会在提交时调用 fsync() 或 fdatasync()，每次提交都要等待设备响应。因此，单个连接的提交速率由写入延迟决定，而不是由带宽决定。刷新耗时 0.2 ms 的设备，每秒允许的提交次数远高于耗时 5 ms 的设备；吞吐量再高也无法改变这一点。当刷新速度跟不上时，MySQL 会在错误日志中明确记录：

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL 会在检查点日志中报告这一情况。其中，较大的 sync= 值表示刷新本身较慢：

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

会处理大量小文件的工作。 每个文件都涉及元数据操作，而一次大型顺序读取不需要进行这些操作。npm install、大型代码仓库的 git clone、解包容器镜像、Maildir 邮件存储，以及遍历大型目录树的备份任务，都会将大量时间花在小块随机访问上。VPS 上的 restic 备份任务会读取并计算此前未处理过的每个文件的哈希值，因此，包含一百万个文件的备份任务，其实际耗时与随机读取延迟密切相关。du -sh 也是如此，因为它只读取元数据。

超过 RAM 容量的数据库也属于这一类。当索引无法继续放入页缓存时，每次查找都会变成随机读取，磁盘重新回到关键路径上。

哪些工作负载不会受到磁盘影响

博客或小型企业网站。 页面体积较小，首次请求后页面缓存即可容纳全部页面；瓶颈在页面渲染所需的 CPU 或静态资源带宽。使用 Ubuntu 24.04 上的 LAMP 堆栈提供低流量网站时，缓存预热后几乎不会产生磁盘 IO。

媒体流传输。 一路 4K 流以 40 Mbit/s 的速率读取 5 MB/s。十路流读取 50 MB/s，即使网络块存储也能轻松提供。在 VPS 上运行 Jellyfin 媒体服务器时，瓶颈在网络出口配额，以及转码时的 CPU，而不是存储介质。

本地模型推理。 在 VPS 上运行 Ollama 以自行托管 LLM时，模型文件只读取一次，之后在 RAM 中运行。NVMe 可将加载 20 GB 模型的时间从数分钟缩短到数秒，但不会改变每秒生成的 token 数量；该指标受内存带宽和 CPU 限制。

任何等待外部服务的工作负载。 如果某个 worker 每项任务要花 800 ms 等待 HTTP 请求，换用更快的磁盘也不会提高处理速度。

虚拟机监控程序与存储介质同样重要的原因

您从不直接与设备通信。您实际使用的是虚拟机监控程序提供的虚拟磁盘，通常通过 virtio 提供。该层的多项配置，其影响可能大于 NVMe 与 SATA 之间的差异。

您无法从客户机内部识别底层存储介质。 lsblk -d -o NAME,ROTA,SIZE,MODEL 显示 vda，但型号为空，因为 virtio 不会传递物理驱动器的身份信息。cat /sys/block/vda/queue/rotational 报告的是虚拟机监控程序公开的信息，因此其中为 0 不能证明存储介质是闪存。nvme list 来自 nvme-cli 软件包。在大多数 VPS 中，即使宿主机装有大量 NVMe 驱动器，它也不会列出任何设备，因为您的磁盘是 virtio 设备，而不是 NVMe 设备。服务方案中写有 NVMe，通常描述的是宿主机中的存储设备。您的卷仍可能通过网络连接。

宿主机的缓存模式对测试结果的影响可能大于存储介质。 如果宿主机启用了回写缓存，客户机中的 fsync() 只要确认宿主机已将数据写入自身 RAM，就可以返回结果。这样的基准测试结果可能超出任何物理设备的实际能力。它还意味着，宿主机崩溃时，数据库认为已经安全的数据可能会丢失。使用缓存模式 none 时，测试结果较低，但更符合实际。

限制和突发额度。 许多服务商会按卷或服务方案限制 IOPS，许多网络卷还使用突发额度。突发额度是一组积分。积分充足时，卷可以高速运行；积分耗尽后，性能会降至低得多的基线水平。其表现很容易识别。导入或恢复操作在开始几分钟运行很快，随后突然明显变慢，并且配置没有任何变化。此时说明突发额度已经耗尽。

邻居虚拟机。 在共享宿主机上，其他客户机的负载会影响您的磁盘延迟。因此需要多次进行测试。早上运行一次相同的测试，晚上再运行一次，然后比较两次结果的差异。在负载较高的宿主机上，同一卷两次测试之间的差异，通常大于服务商公布的两种存储介质之间的差异。

如何测量 VPS 实际拥有的磁盘性能

安装标准 IO 基准测试工具 fio，然后执行测量。先注意以下 3 点。测试会创建文件，因此会占用磁盘空间，并计入计费的 IOPS 配额。每次运行时间应保持较短。不要以完整队列深度对正在提供实时流量的卷运行测试，否则测试会与自己的应用争用资源。

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

队列深度为 32 的随机读取，这是供应商通常提供的指标：

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

需要关注的行以 read: 开头。

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 会绕过客户机页缓存，因此结果反映的是设备性能，而不是 RAM 性能。省略它会测量内存性能，得到磁盘无法达到的数值。如果磁盘空间允许，请使用 --size=4G 或更大的测试文件，因为 1G 文件可能完全位于主机缓存中，从而使结果虚高。

队列深度为 1 时可以显示原始延迟，也就是单线程进程实际感受到的延迟：

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

提交测试用于预测数据库行为。它每次写入 4k，并在每次写入后调用 fdatasync()，因此报告的速率包含刷新操作：

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

该测试得到的 IOPS 数值接近单个数据库连接每秒能够提交的小事务数上限，因为提交操作需要等待相同的刷新完成。

如果需要在不使用 fio 的情况下快速采样：

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

mdev 值表示平均偏差，其重要性不低于平均值。空闲服务器上的较大偏差通常表示存储后端由多个租户共享，并且当前较为繁忙。

如何解读结果

截至 July 2026，对于小型 VPS，可以参考以下判断。队列深度为 32 时，每秒数万次 4k 随机读取 IOPS，且队列深度为 1 时的延迟低于约 0.3 ms，符合本地闪存的表现。队列深度为 1 时延迟达到数毫秒，说明存在网络路径，无论套餐名称是什么。顺序读取速度稳定在约 550 MB/s，通常是 SATA 链路的特征。如果数值远高于任何单个设备的能力，说明链路中存在缓存，几乎总是在主机侧。

要查看当前工作负载对磁盘的影响：

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

在 iostat -x 输出中，查看 r_await 和 w_await，它们分别表示请求等待的平均毫秒数；同时查看 aqu-sz，它表示平均队列长度。在虚拟磁盘上忽略 %util。该指标表示至少有一个请求处于未完成状态的时间占比，无法反映能够同时处理多个请求的设备是否饱和。因此，%util 为 100、而 r_await 为 0.2 ms 时，说明磁盘繁忙但运行正常。在 vmstat 中，wa 列表示 CPU 时间中等待 IO 的百分比。如果内核提供 /proc/pressure/io，其 some avg10= 值表示最近 10 秒内至少有一个任务因 IO 停滞的时间占比。这是判断存储是否为瓶颈最直接的指标。

磁盘受限型 VPS 的表现

负载平均值很高、CPU 处于空闲状态，同时 wa 中的 vmstat 数值较大，说明进程正在磁盘后面排队。最明确的内核信号是 dmesg -T 中的这条消息：

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

这条消息出现的原因是某个内核线程等待存储设备响应超过两分钟，因此 hung task watchdog 记录了该事件。jbd2 是 ext4 日志线程，说明整个文件系统都在等待，而不是某个行为异常的程序导致问题。在 VPS 上，这通常指向存储后端或已耗尽的 IOPS 配额。

应用层面的症状也符合这一模式。中位响应时间仍然可以接受，但最慢请求会形成很长的尾部，因为只有访问磁盘的请求会受到影响。apt upgrade 会在 Unpacking 阶段停留数分钟，因为 dpkg 在写入时会执行 flush。在大型仓库中执行 git status 需要数秒。这些属于元数据和 flush 开销，因此增加带宽并不能解决问题。

磁盘成为瓶颈时的处理方法

先购买内存，再购买 IOPS。 如果工作集可以放入页缓存，读取请求就不会到达磁盘。将内存加倍通常比迁移到更快的存储类别更有效，而且成本通常更低。

在数据允许的情况下，减少刷盘次数。 在 PostgreSQL 中，synchronous_commit = off 允许提交操作在数据写入磁盘前返回。如果服务器发生故障，可能会丢失最后几分之一秒内的事务。数据库不会损坏，因为预写式日志仍会按顺序写入。对于分析副本，这种权衡是合适的；对于支付系统则不合适。MySQL 中的 innodb_flush_log_at_trx_commit = 2 也是同样的权衡。

批量处理小文件。 传输或备份一百万个小文件时，耗时主要来自每个文件的处理开销。因此，在高延迟存储上，先归档，再传输一个数据流，比逐个复制文件树更快。

确保精简卷上的 discard 正常工作。 在精简配置存储上，后端只有在文件系统发出通知后，才知道某个块已空闲。如果卷从不执行 trim，写入性能会逐渐下降。Ubuntu 提供了一个每周运行的计时器：

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av 会输出每个挂载点执行 trim 的字节数。如果提示不支持 discard，说明虚拟磁盘没有将 discard 请求传递给主机，因此无需修复任何配置。

不要调整 I/O 调度器。 在 virtio 磁盘上，cat /sys/block/vda/queue/scheduler 通常已经显示 none，而真正的调度发生在主机上，您无法访问主机。也不要调整 noatime：Ubuntu 默认使用 relatime 挂载，这已经避免了几乎所有 atime 写入。

选择方案

当服务器上运行数据库、邮件服务器、CI runner 或依赖大量软件包的构建任务时，应选择 NVMe。对于缓存型网站，或主要耗时在外部调用上的应用，不要为此支付额外费用。如果无法确定，磁盘可能不是瓶颈，因为大多数小型 VPS 工作负载首先会耗尽 RAM 或带宽。

从第一天开始测量，同时完成新 VPS 上的前十分钟操作，并将输出保存到文件中。基线数据可用于之后证明是主机变慢，而不是代码导致性能下降。优先选择明确说明存储类型和 IOPS 上限的提供商。如果方案标注为 NVMe，但队列深度为 1 的读取耗时 4 ms，则说明你使用的是部署在配备 NVMe 主机上的网络存储。这种产品可以销售，但它与真正的 NVMe 存储不是同一种产品。

FAQ

NVMe 在 VPS 上是否总是比 SATA SSD 更快？

不是。在队列深度为 1 时，两者性能接近，4k 读取延迟大约为 80 至 150 微秒，单线程程序无法区分它们。存在大量并发请求时，NVMe 才会体现优势，因为 AHCI 只有一个队列，深度为 32，而 NVMe 支持数千个更深的队列。在共享主机上，其他虚拟机产生的负载对延迟的影响可能大于存储介质本身。因此，应使用 fio 测量自己的卷，不要只看方案名称。

如何检查 VPS 是否确实使用 NVMe？

无法直接检查，因为 virtio 会隐藏物理设备。lsblk 会显示 vda，但不包含型号字符串；nvme list 不返回任何内容；/sys/block/vda/queue/rotational 只报告虚拟机监控程序公布的信息。应改为测量实际表现。队列深度为 1 的随机 4k 读取延迟低于约 0.3 ms，通常表示使用本地闪存。延迟达到几毫秒，说明路径中可能经过网络。顺序读取速度接近 550 MB/s 后停止，通常表示使用 SATA 链路。

NVMe 会让我的网站加载更快吗？

通常不会。首次请求后，Linux 会将文件从页面缓存中的 RAM 提供出去，因此磁盘会处于空闲状态。小型 VPS 的页面速度通常受应用 CPU 时间和带宽限制。如果网站在每次请求时都写入数据，磁盘会重新进入关键路径。例如，基于数据库且频繁提交的购物车，每次提交都要等待刷新完成。

VPS 的 fio 测试结果达到什么水平才算好？

截至 2026 年 7 月，使用本地闪存的小型 VPS 通常可在队列深度为 32 时达到数万 4k 随机读取 IOPS，队列深度为 1 时的延迟低于 0.3 ms。网络块存储通常达到几千 IOPS，延迟为几毫秒。应在不同时间运行 3 次测试。多次测试结果之间的差异，比平均值更能说明问题，因为它反映了主机上其他虚拟机对你的影响程度。

是否应将数据库放在网络块存储上？

可以，许多托管服务也这样做，但提交路径会因此承担额外开销。每次刷新都要经过网络，因此单个连接每秒提交的小型事务数量会低于使用本地闪存时的数量。作为交换，数据持久性不会受主机故障影响。如果为写入密集型数据库选择网络存储，应将多个操作合并到更大的事务中，让更少的刷新操作携带更多行。