同一块盘写入量差了 11 倍，SSD 写放大到底吃掉了什么

如果你在挑云服务器硬盘、或者在操心自己的云盘能撑几年，这两家以 NVMe 存储为主打的高性能商家可以先看看报价和技术说明：terabix（AMD EPYC Genoa + DDR5 内存 + RAID-10 NVMe Gen4 存储的高端云虚拟机）、itldc（覆盖 20 个全球机房的 NVMe 云盘与独立服务器方案）

去年冬天我接手了一台跑了两年的云服务器，配置普普通通：4 核 8G，100G 系统盘加一块 200G 数据盘。业务方给我的说法是「我们就是每天写几百万行日志，怎么可能把盘写坏」。我信了，直到有一次做容量体检，我顺手看了一眼 SMART 里的写入量计数器。

系统盘 100G，SMART 显示累计写入 4800GB。数据盘 200G，写入量 21000GB。两块盘加起来不到 300G 容量，累计写入 2.5TB。听着好像还行？直到我把业务日志翻出来一算那套系统每天实际产生的日志量，按行数算大概 1.2GB，按字节算更小，撑死一天 2GB 不到。两年下来真实数据量应该在 1.5TB 以内。

也就是说，实际写入 1.5TB 的业务，在盘上变成了 2.5TB 的物理写入量。多出来的部分，就是写放大。

写放大到底是什么，为什么会差出 11 倍

要理解写放大，得先明白 SSD 的存储单元是怎么工作的。机械硬盘是按扇区原地覆盖，写 1KB 就是物理上动 1KB 的磁头。SSD 不是这样，它最小的写入单位叫页（page），典型是 4KB 甚至更大，但擦除的单位是块（block），一个块由几十上百页组成，而且只能整块擦除。

关键矛盾就在这儿：写只影响一页，擦却要抹掉一整个块。假设一个块里有 100 页，只有 1 页需要写新数据，SSD 没办法只擦这一页，它必须把整个块读出来、合并成新数据、写成「擦除态」、再把新数据写回去。真正被业务改动的只有 4KB，实际落到 NAND 上的动作却是几百 KB。写放大系数（Write Amplification Factor，WAF）就是这么来的。

那为什么不同盘能差出 11 倍？三个原因叠加：

一、垃圾回收策略不同。盘里没有空闲块的时候，主控必须主动做垃圾回收（GC），把若干个块里的有效数据合并腾挪出去，才能腾出整块来擦。这个「腾挪擦除写入」的循环本身又是一次写。盘的预留空间（over-provisioning）给得越足，需要搬运的次数越少，写放大越低。廉价消费盘预留空间常常只有 7%，企业盘能给到 28% 甚至更多，这就是同容量价格差一大截的底层原因。

二、负载模式不同。这是我这台机器的真实原因。我的业务日志是「小块高频写 + 几乎不删」，日志文件写满一个就滚动一个，滚动的时候并不真正释放空间，文件系统层看是删了，但盘底层那块空间还留着旧数据，得等 GC 慢慢收。这种负载最伤盘。相反，如果是「大面积顺序写 + 大块删除」，写放大能低到 1.5 倍甚至接近 1。

三、写合并与缓存策略不同。主控有 DRAM 缓存，写请求先进缓存攒批再落盘，攒得越充分，一次擦除前能填满的页就越多，写放大越低。缓存掉电保护（掉电保护电容）做得好不好也影响这一环。

怎么把写放大算到你的账单上

估算盘寿命，核心就两个数：Data Units Written（SMART 属性 235，单位是 1000 个 512 字节扇区）和盘的 Endurance（额定写入量 TBW）。公式很朴素：

可用写入量 = 盘容量 × TBW 系数
实际能撑的天数 = 可用写入量 ÷（日均业务写入量 × 写放大系数）

拿我那台机器算：100G 的盘，标称 300TBW，可用写入量约 30TB。实际日均业务写入 1.2GB，写放大按 5 倍算，日均落盘 6GB。30TB ÷ 6GB 差不多 5000 天，还有富余。可它实际已经写了 4.8TB离极限还早，但带宽、备份周期和「云盘突然被限速」这些麻烦比寿命先到了。

这里要提醒一句：SMART 里看到的写入量本身就是写放大之后的数字，它是盘实际收到并落地的物理写入量。所以拿它直接除以业务量，算出来的是「业务量乘写放大」的合计，不会错，但你得自己去分离出放大系数。方法很简单：业务侧统计一段时间的真实落盘字节数，两者一除就是这台机器当期的真实 WAF。

真正能落地的七条做法

写放大没法彻底消除，但完全可以压下来。以下是我现在给团队定的规矩：

1. 日志别按行刷盘。应用层每写一行就 fsync 一次，是最典型的放大来源。改成批量提交（每 200ms 或每 4KB 攒一次），或者干脆走 page cache 让内核攒批落盘。这一条通常就能把 WAF 从 5 降到 2 以下。

2. 给日志做轮转而不是原地追加。用 logrotate 配 copytruncate 或 create 模式，保证每次轮转产生的是全新文件，删除动作彻底，不给底层留「幽灵占用」。

3. 给盘留出空闲空间。云盘用到 80% 以上就该警觉了。剩余空间越少，GC 越频繁，写放大越高。可以挂个监控，超过 75% 就告警，超过 85% 触发扩容。

4. 确认 TRIM / discard 有没有生效。云环境里如果云盘没开 discard，挂载参数里加 no discard 反而会保留这些好处；但如果底层支持 discard 而文件系统又没主动发 TRIM，删除的数据就只能等 GC 慢慢回收。裸机上通常保留 discard；虚拟机里要问清楚云厂商。

5. 别拿系统盘跑数据库。系统盘上的碎片、更新包、swap、日志混在一起，块尺寸不一，合并效率极低。数据库和日志单独放数据盘，收益立竿见影。

6. 监控 SMART 而不只是容量。至少采集 Data Units Written、Percentage Used、Media and Data Integrity Errors、Unsafe Shutdown Count 这四项。我见过一块盘 Percentage Used 到 3% 就开始报错的，也见过 100% 才出问题的百分比只是参考，实际写入量和错误计数才是真信号。

7. 读多写少的场景别硬上 SSD。如果是归档、日志留存这类写一次读一次的负载，HDD 单位成本上的耐久度碾压 SSD。混合架构往往比全闪存更划算。

选云盘时该问销售的三个问题

买云服务器的时候，别只问「是不是 NVMe」「IOPS 多少」。这三个问题更值钱：

第一，这块盘是共享还是独占？共享盘的写放大系数会随邻居负载波动，你今天测出来的性能明天可能就变了。

第二，给了多少预留空间（over-provisioning）？同一个「100G 云盘」，底层可能是 200G 也可能只有 107G，差别全在这。商家如果讲不清这个数，说明运维团队没摸到盘这一层。

第三，基线 IOPS 是多少，突发积分怎么算？很多云盘的持续性能是按基线给的，超过基线要消耗突发积分，积分用完就限速到基线甚至更低。日志写入突发性大，这一项直接决定你晚上 8 点会不会被限。

回到开头那台机器。我最终没有换盘，而是做了两件事：把日志改成批量提交并单独放到数据盘，把写放大从 5 倍压到 2.1 倍。半年后再看 SMART，累计写入量曲线明显变缓了。盘还是那块盘，但它多活了至少两年。

写放大这件事从来不是硬件的错，是工作负载和配置方式共同决定的。看懂它，你至少能知道自己该在哪一环省。