SSD写入放大问题[转]

Posted 2020-09-16 lnlvinso

     原文地址：http://blog.csdn.net/cywosp/article/details/29812433

 

　　之前在SSD(Solid State Drive)上设计并实现缓存系统用于存储数据块时遇到了一些问题，比如在磁盘写满后，如果老化掉一些最久未使用的数据块后，继续大量写入新的数据，随着时间的推移，写入速度变得比刚开始时慢了许多。为了弄清楚为什么会出现这样的情况，于是在网上搜索了一些关于SSD的资料，原来这种情况是由于SSD硬件设计本身决定的，最终映射到应用程序上该中现象称为写入放大现象(WA: Write amplification)，WA是闪存及SSD相关的一个极为重要的属性，这个术语在2008年被Intel公司和SiliconSystems公司（于2009 年被西部数据收购）第一次提出并在公开稿件里使用。下面简单讲解一下为什么会出现这种情况以及是怎样一个过程。

    SSD的设计完全不同于传统的机械磁盘，其是一个完整的电子设备，没有传统机械盘的读写磁头。因此，在读写数据的时候由于少了磁头在磁道之间的寻道过程所以SSD能提供较高的IOPS性能。也正因为其少了磁头的调度，所以SSD还能减少电量的使用，在数据中心中使用对企业来说是非常有益的。

    SSD与传统磁盘相比其有了很大的性能优势，以及较多的优点，但是事物总是有两面性的，其也自身也存在一些问题，写入在SSD中的数据是不可以直接更新的，只能通过扇区覆盖重写，在覆盖重写之前需要先擦除，而且擦除操作又是不能在扇区上做的，只能在磁盘的块上来完成，擦除块之前需要将原有的还有效的数据先读出，然后在与新来的数据一起写入，这些重复的操作不单会增加写入的数据量 ，还会减少闪存的寿命，更吃光闪存的可用带宽而间接影响随机写入性能。

    举个最简单的例子：当要写入一个4KB的数据时，最坏的情况是一个块里已经没有干净空间了，但有无效的数据可以擦除，所以主控就把所有的数据读到缓存，擦除块，缓存里 更新整个块的数据，再把新数据写回去，这个操作带来的写入放大就是: 实际写4K的数据，造成了整个块（共512KB）的写入操作，那就是放大了128倍。同时还带来了原本只需要简单一步写入4KB的操作变成：闪存读取(512KB)→缓存改（4KB）→闪存擦除（512KB）→闪存写入（512KB），共四步操作，造成延迟大大增加，速度变慢。所以说WA是影响SSD随机写入性能和寿命的关键因素。以100%随机4KB来写入，目前的大多数SSD主控，在最坏的情况下WA可以达到100以上。如果是100%持续的从低LBA写入到高LBA的话，WA可以做到1，实际使用中写入放大会介于这两者之间。SSD的具体操作步骤如下：

　　

2. 写入放大的解决办法

    在实际操作中我们很难完全解决掉SSD写入放大的问题，只能通过某些方法来更有效的减少放大的倍数。一个很简单的办法就是将一块大的SSD硬盘只使用其的一部分容量，比如128GB你只是用64GB，那么最坏的情况就是写入放大能减少约3倍。当然这种方法有点过于浪费资源了。另外还可以在写数据时采用顺序写入，当SSD被顺序写入时，其写入放大一般为1，但某些因素会影响到该值。

    除了上面的方法外，现阶段公认的比较好的方法是TRIM。TRIM位于操作系统层。操作系统使用TRIM命令来通知SSD某个page的数据不需要了，则可以回收。 支持TRIM的操作系统和以往的主要区别是删除一个Page的操作不同。在磁盘时期，删除一个page之后在文件系统的记录信息里将该page的标志位设置为可用，但是并没有将数据删除。使用SSD且支持TRIM的操作系统，在删除一个page时，会同时通知SSD这个page的数据不需要了，SSD内部有一个空闲时刻的垃圾收集进程，在空闲时刻SSD会将一些空闲的数据集中到一起，然后一起Erase。这样每次写操作，就在已经Erase好了的Page上写入新的数据。

 

3. 总结

    虽然其存在写入放大的问题，但是这并没有让我们拒绝使用它。用其来做缓存加速已在很多项目中得到使用，尤其是在数据库缓存项目中，在这些项目中SSD高效的读性能得到了充分的利用。随着Facebook的开源项目Flash Cache的发布，以及Facebook内部的大量使用，Flash Cache已经成为了一个比较成熟的技术方案，这使得更多的公司选择了SSD来做存储或者缓存。

 

 

参考

[1] http://jfwang213.iteye.com/blog/1562263

[2] http://www.pceva.com.cn/topic/crucialssd/index-6_7.html

[3] http://bbs.pceva.com.cn/thread-3653-1-1.html