文档章节

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

n
 nilei
发布于 01/30 11:59
字数 2227
阅读 3394
收藏 70

三周前,我开源了自己写的共识库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支持!

© 著作权归作者所有

共有 人打赏支持
n
粉丝 11
博文 4
码字总数 8121
作品 1
私信 提问
加载中

评论(14)

BaiYang
BaiYang

引用来自“BaiYang”的评论

缓存只适合削峰填谷,处理偶尔的突发密集请求。如果请求一直很密集,那缓存也会很快爆满,然后整个 SSD 回到毫秒级的写延迟。。。以前带电池的 RAID 卡也是这样~

引用来自“dieslrae”的评论

你说的是mq吧.缓存如果是你说的这样,只能说命中率太低了
我说的就是磁盘写 buffer。哪怕带电池 buckup,buffer 满了仍然会回到磁盘的真实 IO 速度。你说的是读 cache,与本文讨论的问题无关。
n
nilei

引用来自“alien_hjy”的评论

1、Google 云 NVME 并不是裸盘给你用,而是在它的 NVME 存储上划分一个逻辑盘给你用,拿逻辑盘来打物理盘打不过不是很正常的吗?
2、NVME 重点从来就不是什么降低 fsync 延迟,NVME 相对 AHCI 来说,就是为了解决 AHCI 的 IOPS 瓶颈而已,NVME 制定以来就一直强调的是 IOPS 性能。(之所以说 AHCI,是因为 NVME 根本不是用来替代 SATA 的,是用来替代 AHCI 的。SATA 是端口标准,NVME 和 AHCI 是传输协议标准,不同类型的标准怎么对比)
3、fsync 延迟和硬盘的物理设计有关,用的什么颗粒,采用什么缓存,传输路径长度,这些才是影响延迟的因素。在性能不足以成为瓶颈的情况下,传输协议(NVME/AHCI)并不会导致延迟有太大影响。这篇文章很容易让初学者误解为 NVME 性能低于 AHCI,而实际上报告中出现的性能指标差异,并不是由 NVME/AHCI 引起的,而是由存储结构、数据传输路径、缓存设置引起的。
NVME 是为了解决极端情况下 AHCI 的并发传输瓶颈问题而产生的,这只是一个传输协议,通常情况下和数据 fsync 落地性能并没很明显的关系。更别说测试数据中的性能表现远远没达到 AHCI 的瓶颈了。。。(唯一一个达到瓶颈的指标是 4096KByte 以后,950pro 传输性能达到 645MB/s,超过了 SATA3 的带宽限制)
1. 逻辑盘和物理盘的差距是毫秒级的吗?请拿出基本逻辑。按照这个滑稽说法,linode, ec2的nvme盘都应该延迟毫秒算。Google云的延迟原因比这个复杂的多。

2. 原文在zhihu首发就明确指出了SATA和NVME不是一个对等的东西,SATA Express可以用NVME。oschina转帖的时候没有附带最后的那段说明,是因为这种咬文嚼字是我所痛恶的。原文链接如下,技术人员还是单纯一点好,咬文嚼字不如去当政工干部啦。

https://zhuanlan.zhihu.com/p/55658164

3. 原文清楚指出fsync的延迟成因,你写了一大段,一无法对我的观点反驳,二不提供新的内容。秀存在感吗?比如,我文章里,清楚的指出NVME有否,不是fsync性能的关键,你绕一大圈,说“通常情况下和数据 fsync 落地性能并没很明显的关系。更别说测试数据中的性能表现远远没达到 AHCI 的瓶颈了”,很滑稽。

4. NVME性能低于AHCI这种滑稽观点,是你在做唯一表述。你先自己胡扯出一个荒谬的说法,然后自己来反驳自己的观点,进而指出我的说法可能误导初学者。这种逻辑,不滑稽吗?
d
dieslrae

引用来自“BaiYang”的评论

缓存只适合削峰填谷,处理偶尔的突发密集请求。如果请求一直很密集,那缓存也会很快爆满,然后整个 SSD 回到毫秒级的写延迟。。。以前带电池的 RAID 卡也是这样~
你说的是mq吧.缓存如果是你说的这样,只能说命中率太低了
alien_hjy
alien_hjy
1、Google 云 NVME 并不是裸盘给你用,而是在它的 NVME 存储上划分一个逻辑盘给你用,拿逻辑盘来打物理盘打不过不是很正常的吗?
2、NVME 重点从来就不是什么降低 fsync 延迟,NVME 相对 AHCI 来说,就是为了解决 AHCI 的 IOPS 瓶颈而已,NVME 制定以来就一直强调的是 IOPS 性能。(之所以说 AHCI,是因为 NVME 根本不是用来替代 SATA 的,是用来替代 AHCI 的。SATA 是端口标准,NVME 和 AHCI 是传输协议标准,不同类型的标准怎么对比)
3、fsync 延迟和硬盘的物理设计有关,用的什么颗粒,采用什么缓存,传输路径长度,这些才是影响延迟的因素。在性能不足以成为瓶颈的情况下,传输协议(NVME/AHCI)并不会导致延迟有太大影响。这篇文章很容易让初学者误解为 NVME 性能低于 AHCI,而实际上报告中出现的性能指标差异,并不是由 NVME/AHCI 引起的,而是由存储结构、数据传输路径、缓存设置引起的。
NVME 是为了解决极端情况下 AHCI 的并发传输瓶颈问题而产生的,这只是一个传输协议,通常情况下和数据 fsync 落地性能并没很明显的关系。更别说测试数据中的性能表现远远没达到 AHCI 的瓶颈了。。。(唯一一个达到瓶颈的指标是 4096KByte 以后,950pro 传输性能达到 645MB/s,超过了 SATA3 的带宽限制)
d
dieslrae
那读性能是不是消费级ssd和企业ssd就没什么差别
BaiYang
BaiYang
缓存只适合削峰填谷,处理偶尔的突发密集请求。如果请求一直很密集,那缓存也会很快爆满,然后整个 SSD 回到毫秒级的写延迟。。。以前带电池的 RAID 卡也是这样~
Lin_1
Lin_1
我感觉你应该在图片上点出一些你所要讲的点 这样对于我这种初学者来说 就很容易看懂了