本帖最后由 nighttob 于 2019-1-31 14:52 编辑
转自：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没有用，那只能说明你找不到合适的应用
|
收藏
转播
