FastCFS性能碾压Ceph之技术揭晓
Posted Huazie
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FastCFS性能碾压Ceph之技术揭晓相关的知识,希望对你有一定的参考价值。
FastCFS性能碾压Ceph之技术揭秘
本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。
FastCFS 已发布了版本 2.2.0,IOPS 全面超越 Ceph:顺序写是Ceph 的 6.x 倍,顺序读是 Ceph 的 2.x 倍,随机写大约是 Ceph 的 2 倍。
具体的性能测试数据参见:https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark.md
相信有很多朋友会好奇 FastCFS 是如何做到的,接下来将为你揭晓 FastCFS IOPS 完胜 Ceph 的秘诀。
我不打算探讨架构和实现细节上的差异,直接为大家揭晓有效提升 IOPS 的关键做法。
FastCFS 基于 trunk 文件(默认大小为 256MB)存储数据,在一个trunk 文件内采用顺序写方式。顺序写可以做到数据批量落盘,能够有效解决写放大问题,决定了 FastCFS 的写入性能相比传统的落盘方式有着明显优势,这就解释了 FastCFS 的随机写大约是 Ceph 的 2 倍。
为啥 FastCFS 顺序写可以秒杀 Ceph 呢?
除了 FastCFS 服务端特有的顺序写机制外,还有一个关键因素是 FastCFS 客户端默认开启合并写特性。分布式存储系统核心性能指标是 IOPS,受制于另外两个IO 能力:磁盘IO 和 网络IO。合并写可以大大提升 网络IO 效率,有效消除 网络IO 瓶颈。
接下来说一下 读性能。
在 v2.2.0 之前,FastCFS 采用传统的同步模型,随机读性能比 Ceph 略差。v2.2.0 采用基于 Linux libaio 的异步模型,随机读性能有所提升,性能比 Ceph 略强。
使用 libaio 异步模型的两大优势:
- CPU 占用较低,一个 异步读线程 处理能力约等于 8~16 个 同步读线程;
- 随机读 IOPS 更好。其代价是实现门槛较高,需要使用 Direct IO,read buffer、文件偏移量 和 读取字节数 都需要按设备块大小对齐(注:块设备大小通常为 512 字节,而不是 4 KB)。
read 使用 异步IO(Direct IO)后,Linux 内核不再缓存读出来的文件内容,需要自己实现预读机制。为了提升顺序读效率,FastCFS 借鉴了 Linux 内核的预读策略,在客户端实现了简洁高效的预读机制。
对于非多节点共享数据(即单节点专享数据)的场景,FastCFS 精心设计和实现的合并写和预读机制不存在数据一致性(比如读到脏数据)问题,故此这两个特性默认是开启的。
更详细的对比测试报告,参见文档【希望有条件的朋友也做一下性能测试】:
https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark-20210621.pdf
在测试和使用过程中,有任何问题,请及时反馈,我们随时准备着与你交流。
友情提示,gitee官网 可以找到我们的联系方式:
https://gitee.com/fastdfs100/FastCFS。
以上是关于FastCFS性能碾压Ceph之技术揭晓的主要内容,如果未能解决你的问题,请参考以下文章