今天遇到了一个比较奇怪的问题，线上的一个 tikv 集群写入时延相比之前增加了不少。看相关指标，瓶颈在磁盘上。节点所在机器的磁盘 latency 达到了 20~30ms 之多，而磁盘吞吐却只有 500MB/S。要知道这可是 nvme。顺序写入甚至可以达到将近 2GB/S。现在却只有 500MB/S。
一开始怀疑是机器问题，排查之后排除了这个猜想。
经同事提醒，想到有没有可能是 trim 的问题，换言之，也就是 ssd 频繁 GC 导致的 latency 上涨。
之前由于硬件原因，关闭了系统自带的定时 trim。
由于这个 tikv 集群目前还处在测试使用阶段，因此直接在某个节点上执行了 trim 操作。正常情况下，该操作要在低峰时间进行，trim 期间磁盘是无法写入的。
果然，经过几秒钟，trim 完成，磁盘 latency 恢复了正常。
为什么会这样呢，这涉及到 ssd 的储存原理。
ssd 主要由以下三部分组成：
- ssd 控制器，用来将 IO 指令翻译成存储陈列的控制信号；控制存储块的 GC 等。
- Flash 存储陈列，由浮栅晶体管组成的存储陈列。
- 与 Host 的接口(SATA,SAS,PCIe)，IO 通信协议。一般 nvme 盘指的就是采用 nvme 协议的 ssd。
ssd 的读写都是以 page 为单位。擦除则是以 block 为单位，一个 block 包含多个 page，也可以做成以字节为单位的擦除，但效率很低。由于这样的设计，导致更新一个 ssd 所在 page 之前， 会将更新的内容写入一个新的空闲 page，然后将原来的 page 标记为无效。长时间的使用，会造成大量的无效 page。这部分 page 需要通过 GC 来回收。
当一块 ssd 被写满，然后又被全部删除之后，这块 ssd 上的数据都还在。那么什么时候会被真正删除呢，在用户更新对应 page 的数据时，ssd 控制器才知道，哦，这个 page 的数据已经被删除了，ssd 将相应 block 的数据迁移到新的空闲 block 的时候，会把对应的 page 删除。而同时这个 block 上的其它 page 可能也已经被删除了，而 ssd 控制器并不知道，这些数据也一并复制过去了。这个过程中无效页会变成空闲页，这也就是 GC 的大致过程。
出问题的这个 tikv 集群之前经过了大量的写入和删除，导致上面的 ssd 的 page 基本上都是标记删除和已使用两种状态。在新写入的时候，需要先擦除，再写入，或者先复制数据，再擦除，再写入，这就是 latency 升高的原因。
trim 的作用是通知 ssd 哪些 page 是应该被删除的，这样 GC 的时候就不会复制已删除的数据，提高了 GC 的效率。同时如果一个块都是被删除的数据的话，则可以直接擦除，然后写入，不需要进行任何数据的迁移。
参考文章：
浅谈分布式存储之SSD基本原理
网友评论