[转贴]硬盘性能的几大误解 - 从共识算法开谈

转自：CNBETA，https://www.cnbeta.com/articles/tech/814349.htm
稿源，开源中国的原文我没找到。

三周前，我开源了自己写的共识库Dragonboat ，在反馈里发现一些用户对硬盘性能有不少基础性误解，但仔细想来这些坑自己一样踏过。本文从一个软件工程师角度，分享一路走来踏过的几个硬盘性能误解，方便大家绕坑而行。

SATA 对 NVME

故事首先是从使用Google云提供的本地NVME盘开始的。“本地NVME盘“，顾名思义，应该是高性能的吧？它IOPS数据靓丽，带着Google招牌的光环，一定不会水啊。跑了一下Dragonboat的跑分模式，得分惨不忍堵，NVME盘跑出的性能比7年前的SATA SSD都烂。
诸如共识算法，各类数据库以及各类需要WAL的软件都需要确保数据确实被保存到硬盘上了，确保比如掉电重启后，数据依旧完好可用。fsync()就是起到这个作用，它确保操作系统缓存内的写数据以及磁盘上缓存的写数据，被确实保存能挺过掉电重启。数据库里一个写数据的transaction和共识算法里一个Proposal的完成，都需要确保数据已落盘，共识算法更需要数据在多数机器上完成落盘。fsync()的延迟性能对上述系统的吞吐均有最直接影响。Google云本地NVME盘的蜗牛速度，是不是fsync()特别慢引起的呢？
祖传工具pg_test_fsync该登场了。
正确测试fsync()相关的各项性能，一大圈工具使用下来加上自己撸的，发现还是PostgreSQL数据库自带的这个pg_test_fsync工具最直观好用。下图是pg_test_fsync在Google云提供的本地NVME盘的跑分结果，Google云本地NVME盘的靓丽IOPS数据下，fsync()每次近需要4.4毫秒，和高速的机械盘一个量级。其他用户也发现了这一奇葩问题。

作为对比，Intel S3700/S3710，Intel 320和镁光500DC等等常见SATA固态硬盘的测试结果显示它们的fsync()延迟是0.15-0.2毫秒左右，比Goole云本地NVME盘足足低几十倍。Intel S3700的pg_test_fsync结果是这样的：

而NVME的Intel P3700的结果如下，差别是客观的，但并不是上述那种几十倍的差距：

以共识算法来说，其理论延迟极限是一次fsync()的延迟加上一次网络RTT延迟。简单计算可知，上述Google云的NVME的fsync()延迟决定了其单client的共识吞吐不可能超过每秒230次，而如果换用SATA的S3700，得益于其0.2毫秒的fsync()，单client共识吞吐理论上限即刻提升为5000次。SATA的S3700秒杀Google云上的奇葩NVME盘。
容量、吞吐、IOPS数甚至寿命都可以通过多盘来堆叠，而这个fsync()延迟，没有任何取巧近路。上述NVME和SATA的对比可见NVME与否并不是最核心的关键因素。SATA与NVME的差异，是几十微秒量级的，而具体差异产生的原因，网络上的介绍文章铺天盖地，这里不复述。上述NVME比SATA慢几十倍的实例，客观显示真正性能差异不在SATA/NVME这一点。

消费级 对 企业级SSD盘

另一常见大坑就是在开发、测试环境上使用消费级SSD，比如三星的NVME M.2固态硬盘价低量足，IOPS数据比肩企业级产品，在非生产环境使用，初一听似乎有一定道理。Dragonboat开发之初，就曾傻傻的拿这样的家用NVME盘去跑测试，结果各种龟速各种悲剧。其实，这种误解用FreeBSD开发人员贴出的数据来对比说明最直接。同样是写盘以后fsync()落盘，比较的是古董级的Intel 710企业级SATA硬盘和高端家用级的Samsung 950 PRO这款NVME盘，家用级是绝对不应该用的，哪怕是开发测试环境：

上述第三方数据也再次验证SATA/NVME的差异不是核心关键，NVME的家用盘的落盘写延迟是古董级Intel 710这款SATA盘的11倍，完全绝对不适用于共识算法、数据库等领域。如果开发测试环境单机吞吐是生产环境的1/10，而这样的差异仅仅是为了几百人民币的固态盘差价，显然是很得不偿失的。

具有掉电保护的缓存

传统的企业级硬盘都带有掉电保护功能，初听起来是一个为数据完整性设计的东西，目的是让硬盘在掉电的时候不丢失其缓存内尚未写入到磁盘的数据。其实有无掉电保护下的缓存恰恰正是上述fsync()性能巨大差异的原因。

Intel P3700拆开后，卡的正面左上角用于掉电保护两颗突起的电容清晰可见
在具有掉电保护企业盘里，当fsync()的时候，数据只要成功写入SSD卡上的内存缓存里就可以回复主机报告落盘完成，因为即使系统突然掉电，电容内的电量足够确保维持供电直到缓存内的数据安全落盘写入NAND。而不具备掉电保护的奇葩级企业盘，比如上述Google云的本地NVME盘，以及NVME的Samsung 950 PRO这款家用盘，每次均必须把数据实打实写到NAND存储芯片里。写NAND的物理延迟就是平均毫秒级别的，这和SATA与NVME均无关。
下图是AnandTech对几种常见NAND芯片性能的比较。以Intel P3700为例，它是最典型MLC NAND的固态盘，所用的NAND的写延迟就是1ms，之所以可以在100微秒内完成落盘，就是因为数据是被在掉电保护机构配合下可靠写入缓存，而非写入了MLC NAND。

此处的一大坑就是过度片面追求SLC/MLC/TLC这类NAND类型带来的性能差异，最好服务器都用SLC/MLC颗粒。这首先不是产品趋势，其次上述的分析已经清楚展示了最直接的吞吐相关的因素是掉电保护系统，恰恰就是通过它完全规避了NAND写延迟，才有良好的落盘写性能。NAND类型真的不必苛求，选大厂比如Intel的企业盘，确保掉电保护的完好性自检没有问题，选写入寿命扛得住的，这才是关键。

Intel傲腾

Optane从原理上避免了对基于内存的缓存的需求，没有了这个内存缓存，自然就不需要掉电保护这一东西。它读写延迟均更低，不用缓存不用掉电保护，落盘写就是在20-30微秒。它除了价格贵，包括寿命在那的各项指标没有一样不出彩的。特别指出这一最新发展，但不做具体展开。
共识算法不需要大量的高速低fsync()延迟存储空间
成熟的共识算法库以及数据库系统，一般均支持指定一个WAL存储位置，将它指向Optane或者带掉电保护的低fsync()延迟的固态盘，对系统性能帮助极大。此类WAL数据一般不大，在不少测试过的场景一般100G左右就足够，这也正是Intel P4801X这样固态盘只有100G大的原因。切勿错误理解为用了共识算法那所有数据都必须放低落盘写延迟的固态盘上。

结论

落盘写延迟是共识算法、数据库等应用最核心硬盘指标
SATA和NVME的落盘写延迟差异，远小于掉电保护的有无带来的延迟差异
家用级与企业级的最根本区别在于是否具有掉电保护，以及掉电保护带来的落盘写延迟差异
PostgreSQL自带的_pg_test_fsync_工具能方便检测落盘写性能，200微秒以上的固态盘建议直接走报废流程或调换至于共识算法、数据库不相关领域。
最后，您试用Dragonboat这款开源共识库了吗？欢迎试用，并点Star支持！

下面是我的解读，因为我不懂数据库和共识算法什么的，所以只从SSD的角度来说

我虽然不懂数据库，但我知道大部分数据库的读写IO模型都是小尺寸数据块，而且是IO密集型
文中提到的WAL，大概查了一下，是一种数据库改写的方式，有日志journal/log的性质在里面。日志也是一种小尺寸IO模型
存储玩家会比较多接触到日志的，我认为应该是ZFS的ZIL
由于实际上ZFS是一种高性能软件存储方案，所以为了同时兼顾性能和可靠性，对ZIL设备的IO性能要求也是极高的
在企业级上面会用内存盘，比如当年sTec的ZeusRAM，当然现在有Optane了
在转的文中也提到，Optane也更适合这个应用

然后就说到“蜗牛一般速度的NVMe”
看过这么多评测，包括作者接下来的测试，都可以知道，问题并不出在NVMe上面，毕竟SSD并不是直通给云用户使用的
那么问题就出在如何把NVMe提供给云用户使用上了，显然这比起Google用了谁家的SSD而言，更加算是商业秘密，但不论如何，并不适合作者的这个应用
作者在测试过手上的S3700和P3700以后，也没有再展开SATA与NVMe的区别，这个大家看相关知识普及和评测也够多了
而且再次强调了，延迟是没有捷径的

后面就说到所谓“跨界”的问题
那些表现光鲜，但一跑应用就原形毕露的发烧级SSD，在PCEVA也被“曝光”过好几回了，但似乎上榜的永远都是三丧
这个710（相当于有完整掉电保护的320）vs 950 PRO的测试，其实也体现了应用这个问题
近两年我们发明了“表面固态”这个词，也许也应该称这些盘是“表面企业级”

掉电保护的重要性，一直以来都是PCEVA所极力主张的
最典型的案例就是论坛定制版建兴T9和OCZ Vector 180卡顿事件
如果经历过那段时间，应该就能明白，不同级别的掉电保护，会给FW策略，以及最终的使用体验带来很大不同
即使没有对这两个事件有了解，看了作者的解释，也应该能大概明白

最后还是要吹一波Optane
我就不再吹了，但说到容量这个事很中肯
有人觉得16G、32G的Optane没有用，那只能说明你找不到合适的应用

企业级的低延迟 的确是家用不可以望颈背的。

简单讲，企业级SSD看中的是性能一致性，延迟等高密度读写场合下才会遇到的问题。

家用SSD看的是跑分的高低（没错就是跑分高低）——连续读写，4K等等。

所以我刚刚买了一个3510 800G，作为我的PR缓存和游戏盘。

optane确实是划时代的产品

傲腾虽好，价格还是太贵了

我手头还有好几块16g的

看的我又想买块3500压压惊

WAL 这DD俺还真就接触过

远程磁盘与本地磁盘在这方面差异巨大 远程磁盘更为友好

什么是远程磁盘呢?   就是指经过另一台电脑中转的磁盘
pcie阵列卡实际是pcie总线上的独立host,  pcie阵列卡的 vd 或带有metadata的 jbod ,  算是典型的远程磁盘

可惜我手边没有物料去测了发截图
LSI 9261 带上家用sata盘(无缓存的盘)
LSI 9460 的 NVMe raid 带上家用nvme盘   
上述两种WAL性能就都很好   当然卡加线就是一笔不小的开支了 也不推荐阵列卡上挂不带完整掉电保护的盘

七月流火 发表于 2019-2-1 08:49
傲腾虽好，价格还是太贵了

16G的不贵

我当年测试过不带断电保护的某ssd的性能，结果是表面的单线程40MB/s写入掉到了5MB/s
http://bbs.pceva.com.cn/thread-121262-1-1.html
不过三星这个性能也太差了吧……

解释下WAL吧，对于数据库这些应用，经常把最后一笔数据append到某个文件，然后fsync
fsync结束之后就认为是落盘了，可以采用各种方法去优化了
100G水平的WAL可能不够，前阵子跑scylla的时候，WAL还是轻松突破50G的，而且我们给的压力也不算很大

文件系统的journal也是类似的功能，但是数据日志一般是可选的（ext系列的jounral有none,ordered,data三个等级，分别是什么都不保护，只保护元数据，保护用户数据的一致性）

zfs这种cow的是另一回事了

eterfinity 发表于 2019-2-1 09:51
WAL 这DD俺还真就接触过

远程磁盘与本地磁盘在这方面差异巨大 远程磁盘更为友好

你这个是带电池的阵列卡？这个电池+缓存部分就允许直接fsync的时候回一个落盘……

至于掉电保护的重要性么
我倒是认为普通家用对性能要求并不是很高
毕竟连cpu-z貌似都没调用sync不是（手动扇子笑）

太多的程序在设计的时候就不会有频繁的sync io，比如复制文件，完全可以在复制完之后再把所有数据落盘
万一中间发生断电，只要fs的元数据不出问题就行了
而数据的完整性，操作系统，特别是文件系统的实现，已经帮我们考虑了各种各样的问题
其中就包括缓存丢失这种情景

相对而言，知乎似乎有人报告有设备在这方面的实现有问题
以至于FUA甚至FLUSH_CACHE指令都没有正确执行
这方面会导致更为危险的问题

当然，如果程序就是需要很高的sync io，那选择有断电保护的ssd，或者是带bbu的raid卡，都是合适的

云提供的本地NVME盘？
俺文盲了，到底是云还是本地？

OstCollector 发表于 2019-2-1 18:14
至于掉电保护的重要性么
我倒是认为普通家用对性能要求并不是很高
毕竟连cpu-z貌似都没调用sync不是（手动 ...

重要的数据, 例如涉及到金额的交易, 记录存好的标准就是机器立刻断电, 这笔记录也不会丢, 所以需要  sync

普通家用当然没谁有这个需求.

redseabay 发表于 2019-2-1 22:03
重要的数据, 例如涉及到金额的交易, 记录存好的标准就是机器立刻断电, 这笔记录也不会丢, 所以需要  sync ...

是啊，所以我也说了，真对这个性能有要求就上企业级或者bbu的raid……

墙上的另一块砖 发表于 2019-2-1 20:46
云提供的本地NVME盘？
俺文盲了，到底是云还是本地？

google云，就当作一个虚拟机，然后映射了一个nvme上面的文件/分区给你用吧

https://www.percona.com/blog/201 ... ce-storage-devices/
https://www.percona.com/blog/201 ... rformance-use-case/
https://serverfault.com/questions/726170/slow-fsync-w-google-clouds-local-ssd-postgresql?rq=1

OstCollector 发表于 2019-2-2 17:29
https://www.percona.com/blog/201 ... ce-storage-devices/
https://www.percona.com/blog/201 ... rforma ...

Intel大法好，520秒全家
不过按照作者的意思，520应该也是cheated？
感觉作者对电容有着强烈的执着

这个测试的目的就是要测fsync()的性能，那么如果Intel是在cheating了，看起来的低延迟也就是无意义的了
这就是挺可怕的一个事了
你有什么看法吗？

vector180卡顿是指删除大文件那个？

StormBolt 发表于 2019-2-2 18:24
vector180卡顿是指删除大文件那个？

那是其中一个表象
跑4K的时候更明显