FastCFS性能碾压Ceph之技术揭晓

Posted Huazie

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FastCFS性能碾压Ceph之技术揭晓相关的知识,希望对你有一定的参考价值。

FastCFS性能碾压Ceph之技术揭秘

本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。

FastCFS 已发布了版本 2.2.0IOPS 全面超越 Ceph:顺序写是Ceph6.x 倍,顺序读是 Ceph2.x 倍,随机写大约是 Ceph2 倍。

具体的性能测试数据参见:https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark.md

相信有很多朋友会好奇 FastCFS 是如何做到的,接下来将为你揭晓 FastCFS IOPS 完胜 Ceph 的秘诀。

我不打算探讨架构和实现细节上的差异,直接为大家揭晓有效提升 IOPS 的关键做法。

FastCFS 基于 trunk 文件(默认大小为 256MB)存储数据,在一个trunk 文件内采用顺序写方式。顺序写可以做到数据批量落盘,能够有效解决写放大问题,决定了 FastCFS 的写入性能相比传统的落盘方式有着明显优势,这就解释了 FastCFS 的随机写大约是 Ceph2 倍。

为啥 FastCFS 顺序写可以秒杀 Ceph 呢?

除了 FastCFS 服务端特有的顺序写机制外,还有一个关键因素是 FastCFS 客户端默认开启合并写特性。分布式存储系统核心性能指标是 IOPS,受制于另外两个IO 能力:磁盘IO网络IO。合并写可以大大提升 网络IO 效率,有效消除 网络IO 瓶颈。

接下来说一下 读性能

v2.2.0 之前,FastCFS 采用传统的同步模型,随机读性能比 Ceph 略差。v2.2.0 采用基于 Linux libaio 的异步模型,随机读性能有所提升,性能比 Ceph 略强。

使用 libaio 异步模型的两大优势:

  1. CPU 占用较低,一个 异步读线程 处理能力约等于 8~16同步读线程
  2. 随机读 IOPS 更好。其代价是实现门槛较高,需要使用 Direct IOread buffer文件偏移量读取字节数 都需要按设备块大小对齐(注:块设备大小通常为 512 字节,而不是 4 KB)。

read 使用 异步IODirect IO)后,Linux 内核不再缓存读出来的文件内容,需要自己实现预读机制。为了提升顺序读效率,FastCFS 借鉴了 Linux 内核的预读策略,在客户端实现了简洁高效的预读机制。

对于非多节点共享数据(即单节点专享数据)的场景,FastCFS 精心设计和实现的合并写和预读机制不存在数据一致性(比如读到脏数据)问题,故此这两个特性默认是开启的。

更详细的对比测试报告,参见文档【希望有条件的朋友也做一下性能测试】:
https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark-20210621.pdf

在测试和使用过程中,有任何问题,请及时反馈,我们随时准备着与你交流。

友情提示,gitee官网 可以找到我们的联系方式:
https://gitee.com/fastdfs100/FastCFS

以上是关于FastCFS性能碾压Ceph之技术揭晓的主要内容,如果未能解决你的问题,请参考以下文章

FastCFS在eRDMA与传统网络环境下对比测试分享

FastCFS之连接管理

FastCFS之连接管理

从传统运维到云运维演进历程之软件定义存储

FastCFS架构之连接篇

从传统运维到云运维演进历程之软件定义存储