NVMe SSD写入速度突然下降？从SLC缓存耗尽到温度降速的排查方法

NVMe SSD写入速度突然下降？从SLC缓存耗尽到温度降速的排查方法

在 Linux 服务器、工作站和高速存储设备中，NVMe SSD 经常会出现一种容易误判的现象：刚开始写入速度很高，运行一段时间后速度明显下降，甚至出现周期性波动。

有些设备在短时间写入测试中表现很好，但面对大文件复制、虚拟机镜像导入、数据库备份或持续日志写入时，性能却与标称值相差较大。

这不一定意味着 SSD 已经损坏。常见原因包括动态 SLC 缓存耗尽、温度触发限速、后台垃圾回收、系统 I/O 队列拥塞，以及设备健康状态异常。

SLC 缓存是部分 SSD 利用闪存工作模式或专用缓存区域暂存写入数据的机制。缓存充足时，写入速度可能较高；缓存用尽后，数据需要直接写入 TLC 或 QLC 闪存，持续写入性能就可能下降。具体变化幅度取决于控制器、闪存类型、固件、剩余空间和工作负载，不能只凭一次短时测试判断 SSD 的持续性能。

本文从可复现测试、温度监控、Linux I/O 指标和 NVMe 健康日志四个方面，介绍如何定位性能下降的原因。

一、为什么SSD刚开始写得很快，过一会儿就变慢？

首先要区分短时峰值性能与持续写入性能。

部分 SSD 会利用 SLC 缓存吸收突发写入。当缓存尚有空间时，数据可以较快写入缓存区域；当缓存逐渐耗尽，设备需要将数据写入原生闪存，或者同时执行缓存整理和垃圾回收，写入速度便可能下降。

例如，某款 SSD 在短时间测试中可以达到较高的顺序写入速度，但持续写入数百 GB 数据后，速度出现明显下降。这里的"数百 GB"只是用于说明测试规模的示例，并不代表所有 SSD 的缓存容量或降速阈值。

实际测试中，应重点记录以下信息：

1、开始写入时的速度。

2、写入持续一段时间后的速度。

3、速度下降发生的时间点及累计写入量。

4、测试过程中 SSD 温度的变化。

5、测试前后的剩余空间与设备健康信息。

如果写入速度在相近的累计写入量附近反复下降，而且温度没有明显变化，就值得进一步检查 SLC 缓存耗尽和后台整理行为。但这只能作为排查线索，不能单独作为最终结论。

二、怎样判断是SLC缓存耗尽，还是SSD温度过高？

这两类问题都可能导致写入速度下降，但发生规律和验证方式有所不同。

| 观察现象 | 更值得检查的方向 | 验证方法 |

| 刚开始速度高，持续写入后下降 | SLC缓存耗尽、后台整理 | 记录速度与累计写入量的关系 |

| 温度逐渐升高后速度下降 | 温度限制或散热不足 | 同步记录温度和写入速度 |

| 停止写入并冷却后性能恢复 | 温度影响的可能性增加 | 保持测试条件一致，进行冷却前后对比 |

| 速度反复波动，且与温度关系不明显 | 垃圾回收、缓存动态变化、后台 I/O | 检查剩余空间和系统 I/O 状态 |

| 速度下降同时出现错误计数或健康告警 | 设备健康或连接问题 | 检查 NVMe SMART 和错误日志 |

需要注意，缓存耗尽与温度限制可能同时出现。持续写入会增加控制器与闪存的工作负载，也可能导致温度上升。因此，不能只看到速度下降就断定是缓存问题，也不能只凭温度较高就认定 SSD 已经触发限速。

更可靠的方法是同步记录速度、温度和累计写入量，再通过重复测试观察它们之间的关系。

三、Linux下如何记录NVMe温度和健康状态？

Linux 可以使用 nvme-cli 查看 NVMe 设备的 SMART/健康日志。该工具能够读取温度、可用备用空间、设备使用寿命估计、累计读写量以及介质错误等信息。不同 SSD 支持的字段和附加日志可能有所区别。<Cite refs={"turn145254search5","turn145254search9"}/>

先确认设备名称：

nvme list

查看设备健康日志：

sudo nvme smart-log /dev/nvme0

这里的 /dev/nvme0 只是示例设备名。执行前应根据 nvme list 的实际输出替换，避免检查错设备。

重点关注以下字段：

| 字段 | 含义 | 排查价值 |

| temperature | 控制器报告的综合温度 | 观察测试期间的温度变化 |

| available_spare | 可用备用空间比例 | 判断备用空间是否接近设备报告的阈值 |

| percentage_used | 设备报告的寿命使用估计值 | 作为磨损状态的参考 |

| data_units_written | 主机写入数据量统计 | 观察累计写入量的变化 |

| media_errors | 介质相关错误计数 | 判断是否存在需要进一步调查的错误 |

| num_err_log_entries | 错误日志条目数 | 结合错误日志分析设备异常 |

这些字段不能单独作为故障结论。例如，percentage_used 是设备根据自身寿命模型报告的估计值，不等同于精确的剩余寿命；media_errors 的含义也应结合设备文档和错误日志判断。

如果设备报告温度阈值相关字段，可以进一步查看警告温度阈值、临界温度阈值，以及设备记录的温度超限时间。NVMe 标准相关数据结构包含综合温度、温度阈值和温度超限时间等信息，但具体阈值由设备能力决定。<Cite refs={"turn145254search4","turn145254search8"}/>

建议在持续写入测试开始前、速度下降时以及测试结束后分别保存日志，方便比较变化，而不是只读取一次当前温度。

四、为什么不能只看SSD标称速度？

SSD 标称的顺序读写速度通常是在特定测试条件下获得的。实际性能还会受到容量规格、剩余空间、缓存状态、测试文件大小、队列深度、数据模式和系统环境影响。

例如，同一系列 SSD 的不同容量版本，可能采用不同的闪存颗粒数量或内部并行结构，持续写入性能未必完全一致。

测试时还应区分以下几个指标：

1、短时顺序写入速度：主要反映设备在特定测试条件下的突发写入能力。

2、持续顺序写入速度：反映长时间连续写入时的表现，更适合评估大文件和批量数据导入场景。

3、随机写入性能：反映大量小块、分散 I/O 的处理能力，与顺序写入不能直接等同。

4、延迟和延迟波动：反映每次 I/O 请求完成所需的时间及其稳定性。对于数据库和虚拟化业务，延迟可能比单纯的峰值带宽更重要。

因此，如果 SSD 用于数据库、虚拟机或持续日志写入场景，应采用接近真实业务的数据块大小、读写比例和并发程度进行验证，而不是只运行一次大块顺序写入测试。

五、怎样使用fio验证持续写入性能？

fio 是常见的 I/O 压力测试工具，可用于构建顺序写入、随机读写和不同队列深度的测试负载。但测试前必须明确目标设备、测试文件和数据安全边界。

推荐优先对专门的测试文件或测试卷进行测试，不要直接对含有重要数据的原始设备执行破坏性写入。

例如，可以在确认容量充足的测试目录中创建一个测试文件，运行持续顺序写入测试：

fio --name=seqwrite \
    --filename=/mnt/test/ssd-test.bin \
    --size=20G \
    --rw=write \
    --bs=1M \
    --iodepth=16 \
    --direct=1 \
    --runtime=120 \
    --time_based \
    --group_reporting

以上命令只是测试示例，执行前应确认 /mnt/test 是目标测试目录，并且有足够空间。测试文件可能覆盖同名文件中的原有数据，不要将路径指向重要业务文件。

这组参数的含义如下：

| 参数 | 作用 |

| --rw=write | 执行顺序写入 |

| --bs=1M | 每次 I/O 使用 1 MiB 数据块 |

| --iodepth=16 | 设置目标 I/O 队列深度 |

| --direct=1 | 尽量绕过操作系统页缓存 |

| --runtime=120 | 设定测试运行时间为120秒 |

| --time_based | 按设定时间持续运行测试 |

需要注意，120秒未必足以耗尽较大 SSD 的写入缓存。测试时长和写入规模应根据设备容量、缓存特性及实际工作负载调整。测试文件过小或持续时间过短，都可能只测到缓存阶段的峰值性能。

如果目的是研究缓存耗尽后的持续写入能力，应记录每个时间段的吞吐量，并延长测试时间至出现稳定的性能变化。同时，应避免在生产业务高峰期进行压力测试。

六、测试时怎样区分缓存问题、温度问题和系统I/O瓶颈？

建议同时记录 SSD 吞吐量、温度和系统 I/O 状态。

可以使用以下工具观察不同层面的指标：

iostat -x 1

iostat 可以按秒输出块设备统计。常见字段包括：

| 字段 | 含义 | 注意事项 |

| r/s、w/s | 每秒读写请求数 | 观察 I/O 请求频率 |

| rMB/s、wMB/s | 每秒读取或写入的数据量 | 观察吞吐量变化 |

| await | I/O 请求的平均等待与处理时间 | 需要结合设备和内核统计口径理解 |

| aqu-sz | 平均队列长度 | 判断是否存在 I/O 排队 |

| %util | 设备忙碌时间比例相关指标 | 对现代 NVMe 并行设备不能简单当作性能上限 |

具体字段名称会随 sysstat 版本和显示单位有所不同。

如果吞吐量下降，同时队列长度和 await 明显上升，应检查是否存在系统 I/O 排队、其他进程争用或设备内部延迟增加。如果吞吐量下降时队列并不高，则应继续核对缓存状态、温度和设备自身日志。

不要仅凭 %util 接近100%就断定 NVMe 已达到性能上限。现代 NVMe 设备能够并行处理多个队列和大量请求，单一利用率字段不足以完整描述其内部负载。

七、SSD剩余空间会影响持续写入吗？

会，部分 SSD 在剩余空间较少时，持续写入表现可能发生变化。

SSD 需要进行闪存块管理、垃圾回收和磨损均衡。由于 NAND 闪存不能像内存一样直接覆盖写入已有数据，控制器可能需要先整理有效数据，再擦除并复用闪存块。

当设备剩余可用空间较少、持续写入压力较大时，后台整理可能增加，进而影响写入延迟和吞吐量。不过，不同 SSD 的控制器策略、预留空间和固件算法不同，不能用一个固定剩余空间百分比作为所有设备的通用故障阈值。

排查时应记录测试前的可用空间，检查是否有大量临时文件、快照或日志占用了容量，并结合厂商建议评估预留空间策略。

对于业务盘，不应为了追求测试成绩随意删除文件或执行格式化。应先确认数据备份和业务风险，再决定是否进行空间整理或重新测试。

在企业网络与存储设备的部署中，性能排查不仅要关注核心设备，也要重视配套连接产品的规格匹配。例如，在使用胜为相关网络与连接产品进行设备部署时，应根据实际接口类型、传输要求和设备兼容性核对产品参数。需要注意的是，SSD持续写入降速通常应优先从存储设备自身的缓存、温度、健康状态及系统I/O负载入手，不能将存储性能问题直接归因于外部连接产品。

八、建立一套可复现的NVMe性能排查流程

当 SSD 出现写入速度下降时，可以按照以下顺序执行：

1、记录设备型号、固件版本、容量规格和当前可用空间。

2、读取 NVMe SMART/健康日志，保存温度、累计写入量、寿命估计和错误计数。

3、在安全的测试卷或测试文件上运行顺序写入测试，并记录分阶段吞吐量。

4、同步监控温度，观察性能下降是否与温度变化一致。

5、使用 iostat 观察吞吐量、请求延迟和队列长度，判断系统是否存在 I/O 排队。

6、在相同测试条件下重复测试，比较性能下降发生的时间和累计写入量是否接近。

7、如果出现介质错误、关键健康告警或持续异常延迟，应优先备份重要数据，并结合设备厂商的诊断工具进一步检查。

排查过程中应一次只改变一个主要变量，例如测试时长、散热条件或工作负载。否则即使性能恢复，也难以确认真正起作用的因素。

结语

NVMe SSD 持续写入速度下降，并不一定意味着设备故障。SLC 缓存耗尽、温度限制、后台垃圾回收、剩余空间不足和系统 I/O 排队，都可能产生相似的表现。

有效的排查方法，是把分阶段写入速度、温度、NVMe 健康日志和 Linux I/O 指标放在一起分析。通过安全、可重复的测试，才能区分短时峰值性能与持续工作能力，并确定是否需要改善散热、调整测试方法、优化业务 I/O 或进一步检查设备健康状态。