PCEVA,PC绝对领域,探寻真正的电脑知识

标题: [转贴]硬盘性能的几大误解 - 从共识算法开谈 [打印本页]

作者: nighttob    时间: 2019-1-31 14:48
标题: [转贴]硬盘性能的几大误解 - 从共识算法开谈
本帖最后由 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毫秒,和高速的机械盘一个量级。其他用户也发现了这一奇葩问题。
[attach]416990[/attach]
作为对比,Intel S3700/S3710,Intel 320和镁光500DC等等常见SATA固态硬盘的测试结果显示它们的fsync()延迟是0.15-0.2毫秒左右,比Goole云本地NVME盘足足低几十倍。Intel S3700的pg_test_fsync结果是这样的:
[attach]416991[/attach]
而NVME的Intel P3700的结果如下,差别是客观的,但并不是上述那种几十倍的差距:
[attach]416992[/attach]
以共识算法来说,其理论延迟极限是一次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盘,家用级是绝对不应该用的,哪怕是开发测试环境:
[attach]416993[/attach]
上述第三方数据也再次验证SATA/NVME的差异不是核心关键,NVME的家用盘的落盘写延迟是古董级Intel 710这款SATA盘的11倍,完全绝对不适用于共识算法、数据库等领域。如果开发测试环境单机吞吐是生产环境的1/10,而这样的差异仅仅是为了几百人民币的固态盘差价,显然是很得不偿失的。

具有掉电保护的缓存

传统的企业级硬盘都带有掉电保护功能,初听起来是一个为数据完整性设计的东西,目的是让硬盘在掉电的时候不丢失其缓存内尚未写入到磁盘的数据。其实有无掉电保护下的缓存恰恰正是上述fsync()性能巨大差异的原因。
[attach]416994[/attach]
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。
[attach]416995[/attach]
此处的一大坑就是过度片面追求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没有用,那只能说明你找不到合适的应用

作者: ninjasex    时间: 2019-1-31 16:48
企业级的低延迟 的确是家用不可以望颈背的。
作者: 沙漠之鹰L3    时间: 2019-1-31 22:47
简单讲,企业级SSD看中的是性能一致性,延迟等高密度读写场合下才会遇到的问题。

家用SSD看的是跑分的高低(没错就是跑分高低)——连续读写,4K等等。

所以我刚刚买了一个3510 800G,作为我的PR缓存和游戏盘。
作者: 暴力SSD    时间: 2019-1-31 22:48
optane确实是划时代的产品

作者: 七月流火    时间: 2019-2-1 08:49
傲腾虽好,价格还是太贵了
作者: doymll    时间: 2019-2-1 09:02
我手头还有好几块16g的
作者: 羽落风尘    时间: 2019-2-1 09:36
看的我又想买块3500压压惊

作者: eterfinity    时间: 2019-2-1 09:51
本帖最后由 eterfinity 于 2019-2-1 10:04 编辑

WAL 这DD俺还真就接触过

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

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

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




作者: Atom    时间: 2019-2-1 17:53
七月流火 发表于 2019-2-1 08:49
傲腾虽好,价格还是太贵了

16G的不贵

作者: OstCollector    时间: 2019-2-1 17:53
我当年测试过不带断电保护的某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的是另一回事了
作者: OstCollector    时间: 2019-2-1 17:56
eterfinity 发表于 2019-2-1 09:51
WAL 这DD俺还真就接触过

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

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

作者: OstCollector    时间: 2019-2-1 18:14
至于掉电保护的重要性么
我倒是认为普通家用对性能要求并不是很高
毕竟连cpu-z貌似都没调用sync不是(手动扇子笑)

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

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

当然,如果程序就是需要很高的sync io,那选择有断电保护的ssd,或者是带bbu的raid卡,都是合适的
作者: 墙上的另一块砖    时间: 2019-2-1 20:46
云提供的本地NVME盘?
俺文盲了,到底是云还是本地?
作者: redseabay    时间: 2019-2-1 22:03
OstCollector 发表于 2019-2-1 18:14
至于掉电保护的重要性么
我倒是认为普通家用对性能要求并不是很高
毕竟连cpu-z貌似都没调用sync不是(手动 ...

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

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



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

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

作者: OstCollector    时间: 2019-2-1 23:04
墙上的另一块砖 发表于 2019-2-1 20:46
云提供的本地NVME盘?
俺文盲了,到底是云还是本地?

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

作者: OstCollector    时间: 2019-2-2 17:29
本帖最后由 OstCollector 于 2019-2-2 17:31 编辑

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
作者: nighttob    时间: 2019-2-2 18:05
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了,看起来的低延迟也就是无意义的了
这就是挺可怕的一个事了
你有什么看法吗?


作者: StormBolt    时间: 2019-2-2 18:24
vector180卡顿是指删除大文件那个?
作者: nighttob    时间: 2019-2-2 19:40
StormBolt 发表于 2019-2-2 18:24
vector180卡顿是指删除大文件那个?

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


作者: OstCollector    时间: 2019-2-2 20:32
nighttob 发表于 2019-2-2 18:05
Intel大法好,520秒全家
不过按照作者的意思,520应该也是cheated?
感觉作者对电容有着强烈的执着

intel 520 我没什么了解,我觉得如果ssd带断电保护,那么fsync可以做的比较快毕竟能把write-through优化成write-back

作者: nighttob    时间: 2019-2-2 21:02
OstCollector 发表于 2019-2-2 20:32
intel 520 我没什么了解,我觉得如果ssd带断电保护,那么fsync可以做的比较快毕竟能把write-through优化 ...

是这个道理

就是你转贴的这老外认为S3100是没有电容的,所以相当于开了always write back,在worst case下WAL就GG了
但他也说了,做read cache是OK的
话说S3100的相关讨论真是少


作者: 羽落风尘    时间: 2019-2-5 23:33
S3500这种盘是否适合家用?每天都会开关机。


还有里面的断电保护电容时间长了会不会老化失效,网上下载了Intel SSD Data Center Tool想看一下电容状态,但安装后打开一秒后窗口就消失了,不知什么原因
作者: nighttob    时间: 2019-2-6 09:38
羽落风尘 发表于 2019-2-5 23:33
S3500这种盘是否适合家用?每天都会开关机。

我的态度一直是,有企业级需求就该用,否则就是瞎用
瞎用的意思就是,企业级的好处一项都发挥不出来,相反短处是都占上了,而且成本也得背着
论坛里说企业级好处的帖子也有不少,可以自己对一对,自己分析一下
举最简单的例子,写入寿命,如果日常连0.1DWPD都没有,那这个所谓好处就没用,SSD的失效原因绝不仅仅是NAND擦除失效

S3500上的是储能用的电解电容,充放电循环寿命相对较低
在真正7x24环境下,一年也不见得能断几回电,所以不用担心循环次数的问题
家用每天都关机,甚至还会休眠,显然增加了电容方面的损耗,但我认为就算这样也用不到坏的那一天
我认为实际问题是电容充电需要时间,检测电容状态也要时间,所以ready on time会比较长,机器启动太快就直接把SSD miss掉了,这事也发生过了

电容的状态没什么好纠结的
我相信这个盘有坏的那一天也不是因为显性的故障导致的
据我所知isdct是命令行工具,所以你双击当然没用


作者: 973204    时间: 2019-2-12 14:56
就是说家用就买家用的,用不着买企业级别的!想想写入量真还用不上这么高级的!
作者: haierccc    时间: 2019-2-25 21:19
本帖最后由 haierccc 于 2019-2-25 21:42 编辑

有几个不明白的地方:
1.哪怕是家用级SSD也有RAM缓存,比如256G的950Pro有512MB LPDDR3缓存,既然数据已经写入了缓存,就应该报告了啊,难道还要等到写入了NAND才报告?那缓存的“快速写入”的意义又何在呢?因为收到“确认落地写入”报告的延迟=RAM缓存写入延迟+NAND写入延迟,延迟反而增加了。抑或我的算法不对?
2.“比950Pro贵几百元的企业级”是什么型号。我查企业级SSD都是4000+的价格。如果能买到低延迟的、便宜的企业级SSD当然是善莫大焉。

作者: redseabay    时间: 2019-2-25 21:54
本帖最后由 redseabay 于 2019-2-25 21:55 编辑
haierccc 发表于 2019-2-25 21:19
有几个不明白的地方:
1.哪怕是家用级SSD也有RAM缓存,比如256G的950Pro有512MB LPDDR3缓存,既然数据已经 ...

没有电池/储能电容的情况下, 写入ram 就认为写入完毕, 告诉os/应用软件完成写入, 企业级是不可能接受的, 这个时候万一掉电了, 数据就丢了.

其实消费级用途硬盘也不应该欺骗操作系统, os告诉你, 这个写入要落盘, 就要落盘, 否则机器掉电了, 说不定文件系统就坏了.

有储能电容的时候, 写入ram 可以告诉上层, 已经完成写入了, 万一掉电了, 硬盘上的电容够支撑将ram 的东西写入到 flash 中就行.




作者: nighttob    时间: 2019-2-25 22:26
haierccc 发表于 2019-2-25 21:19
有几个不明白的地方:
1.哪怕是家用级SSD也有RAM缓存,比如256G的950Pro有512MB LPDDR3缓存,既然数据已经 ...

上完课老师说听懂了吗,下面都说听懂了,第二天考试就知道谁是真懂了
那就看你是认为吃饭只是把食物送进嘴里,还是在肠胃里消化掉了才算完


作者: feve    时间: 2019-2-28 21:08
作者来个GOOGLE云盘这个是KVM,如何分配看GOOGLE,只是正好既然如此就在差异环境下dragonboat跑个分做对比用而已。
跑pg_test_fsync这个实际是告诉大家物理环境性能情况。
至于下面引用的是另外一个作者写了套代码测试企业和家用新延迟和吞吐。
然后作者告诉大家企业盘因写到缓存就回复写入所以延迟相对低,总结跑共识算法低延迟是指标,容量速度可以叠盘。

--
GITHUB那里我稍微看了下,属于分布式系统的范畴。
共识这个简单参照比特币里的机制相关会有一定了解。
至于数据库入门我视频有大概说明。http://www.iqiyi.com/u/2074832227/v

--
然后到你的结论中“即使没有对这两个事件有了解,看了作者的解释,也应该能大概明白”

这个首先不否认掉电保护的重要性。但这好像和你引用文章作者所说的和你说的没什么关联。
作者所说具有掉电保护的盘主要是在说有掉电保护的盘他是数据写到缓存即可回复已写入由此延迟低。

拿实例来说,WEBSOCKET CHAT,后端UWSGI-PY-redis-postgresql,在服务器上,要做数据掉电保护数据可不是只要保护硬盘缓存写入硬盘这一部分就可以了的。内存的数据同样一起要保护。除非都不重要,几秒的数据没了也没差。当然如果是大数据企业,保护手段会做更多。

很多东西不要混到一起,不然逻辑混乱。
家用选择就是看厂家实力质量品牌价格售后之间取平衡,负责的话确实要告诉买家只在厂家实力足质量好口碑好的厂家之间选,还有就是要告知实际情况的负载,除非很寂寞专门买两个盘while 1 shutil.move一直把同样的文件在两个硬盘中剪切来剪切去。
至于数据掉电保护,不止看个盘掉电保护的,不同性质企业都有不同的做法很多考量,分布部署备份上云等等一大堆手法。

作者: nighttob    时间: 2019-2-28 21:32
feve 发表于 2019-2-28 21:08
作者来个GOOGLE云盘这个是KVM,如何分配看GOOGLE,只是正好既然如此就在差异环境下dragonboat跑个分做对比 ...

你说的对
我实际上是硬拉到一起的

因为我要找我能理解也能表达出来的,好让“吃瓜群众”稍微看明白这个事
虽然从结果上来看也没达到目的

翻回头去看,原作者这个切入点也不是很妥
但转过来,我还添油加醋那么些,目的就是表达“需求和应用挂钩”这个意思
只不过原文说的是别拿半吊子的东西糊弄专业应用,我想说的正好相反


作者: kof758    时间: 2019-3-22 09:45
少2跟线。。。  




欢迎光临 PCEVA,PC绝对领域,探寻真正的电脑知识 (https://bbs.pceva.com.cn/) Powered by Discuz! X3.2