guoqin看这里!谈谈个人对cephfs的性能优化

最近接触到ceph的分布式存储系统感觉非常强大，但在测试环境VM虚拟机上部署后，cephfs性能测试总是达不到基本磁盘的十分之一。

以下是我测试结果的主要工具。这是sysbench基于io的随机写入性能测试。

这里先放一张优化的测试截图。

文件块4K 3个文件共3G

[hs admin @ test 27 upload]$ sys bench fileio-file-total-size=3g-file-test-mode=rn dww

结果我们查看了：

基本磁盘随机写入测试屏幕截图

cephfs随机写入性能测试屏幕截图

Cepffs – IOPS:95.61吞吐量：0.37M/S本机磁盘： IOPS:355吞吐量： 1.39M/S性能降低三倍以上

以下是随机读取测试文件block块4K 3个文件共3G。

sys bench fileio-file-total-size=3g-file-test-mode=rnd rd-max-time=60-

基本磁盘：

Cephfs:

读取性能cephfs比主磁盘高一点

以下是DD写入速度测量：

Cephfs:

基本磁盘：

Cephfs优化后，您会发现写入速度比主磁盘快一点

上述测试结果在虚拟机环境中测试取得了良好的效果。同时，查看官网发现，这是因为cephfs本身的体系结构。(至于为什么这么慢，我就不告诉大家可以去看cephfs的架构了。)性能可能有点缺陷。在没有优化之前，sysbench IOPs只有10-20 DD写测试10-40M/s，ceph官方群也知道很多人遇到过这种情况，因此产生了共鸣。本人看了优化，大致看到IOPs能达到100多dd写。

上述测试结果可能有偏差，但大体结果仍然正确。

那就谈谈我的优化方法吧。

1.硬件级别

硬件规划

Cpu

内存

磁盘类型(SSD暂时不使用，是SATA硬盘，以后将对SSD和SATA进行混合测试。）

BIOS设置

2.软件级别

Linux操作系统

Ceph Configurations

调整Pg编号

CRUSH Map

其他因素

硬件优化

1.硬件规划

1.1处理器处理器

由于Ceph-osd进程在执行过程中消耗CPU资源，因此通常为每个ceph-osd进程绑定CPU核心。

ceph-mon进程并不十分消耗CPU资源，所以不必为ceph-mon进程预留过多的CPU资源。

ceph-mds也是非常消耗CPU资源的，所以需要提供更多的CPU资源.之前测试过程中分配给mds资源少了出现了cpu瓶颈

1.2 内存资源

ceph-mon和ceph-mds官方建议需要2G内存，每个ceph-osd进程需要1G内存，当然2G更好。

1.3 网络规划

万兆网络现在基本上是跑Ceph必备的，网络规划上，也尽量考虑分离cilent和cluster网络。目前我的client跟cluster是在两个不同的网段上这样能保证网络的通畅简洁

2. SSD选择

硬件的选择也直接决定了Ceph集群的性能，参考网上资料我了解到400G的规格4K随机写可以达到11000 IOPS。如果在预算足够的情况下，推荐使用SSD(当然是你很有钱呦)，性能会得到进一步提升，但是由于Journal在向数据盘写入数据时Block后续请求，所以Journal的加入并未呈现出想象中的性能提升，但是的确会对Latency有很大的改善。

3. BIOS设置

Hyper-Threading(HT)

基本做云平台的，VT和HT打开都是必须的，超线程技术(HT)就是利用特殊的硬件指令，把两个逻辑内核模拟成两个物理芯片，让单个处理器都能使用线程级并行计算，进而兼容多线程操作系统和软件，减少了CPU的闲置时间，提高的CPU的运行效率。

软件优化

1. Linux OS 操作系统层面

Kernel pid max-系统最大线程数

echo 4194303 > /proc/sys/kernel/pid_max

2. 提升网络传输大小,交换机端需要支持该功能，系统网卡设置才有效果

ifconfig eth0 mtu 9000

永久设置

echo "MTU=9000" | tee -a /etc/sysconfig/network-script/ifcfg-eth0

/etc restart

3.read_ahead, 通过数据预读并且记载到随机访问内存方式提高磁盘读操作，查看默认值

cat /sys/block/sda/queue/read_ahead_kb

根据一些Ceph的公开分享，8192是比较理想的值

echo "8192" > /sys/block/sda/queue/read_ahead_kb

4. swappiness, 主要控制系统对swap的使用，这个参数的调整最先见于UnitedStack公开的文档中，猜测调整的原因主要是使用swap会影响系统的性能。

echo "vm.swappiness = 0" | tee -a /etc

5. I/O Scheduler，关于I/O Scheculder调度策略可以看看linux方面的资料，这里不再赘述，这个对操作系统的写入性能影响很深,简单说SSD要用noop，SATA/SAS使用deadline。

echo "deadline" > /sys/block/sd[x]/queue/scheduler

echo "noop" > /sys/block/sd[x]/queue/scheduler

6.mount挂载优化

官方提供了两种挂载方式不过比较灵活的是ceph-fuse,但是FUSE的IO Path较长，会先从用户态调用到内核态过程很长 所以在这里我推荐使用Kernel Driver形式挂载

其次是mount挂载参数方面:比如这个

192.168.1.41:6789:/ /upload ceph name=admin,secretfile=/etc/ce 0 0

noatime(减少文件的时间戳记录次数),nodiratime(减少文件夹的时间戳记录次数),async(异步IO) 这些都能显著提高磁盘的IO 效率

ceph本身配置文件优化:

2. Ceph Configurations

下面是我正在使用的配置

[global]
fsid = 7888622e-2f9b-47eb-9d7b-d216de083871
mon_initial_members = ceph-admin, ceph-node1, ceph-node2
mon_host = 192.168.1.41, 192.168.1.42, 192.168.1.43
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
osd pool default size = 3
public network = 192.168.1.0/24
cluster network = 192.168.1.0/24
max open files = 65536
osd pool default min size = 1
#############################################################
[mon]
mon data = /var/lib/ceph/mon/ceph-$id
mon clock drift allowed = 1 #默认值0.05#monitor间的clock drift
mon osd min down reporters = 2 #默认值1#向monitor报告down的最小OSD数
mon osd down out interval = 600 #默认值300 #标记一个OSD状态为down和out之前ceph等待的秒数
mon allow pool delete = true
##############################################################
[osd]
osd data = /var/lib/ceph/osd/ceph-$id
osd journal size = 20000 #默认5120 #osd journal大小
osd journal = /var/lib/ceph/osd/$cluster-$id/journal #osd journal 位置
osd mkfs type = xfs #格式化系统类型
osd mkfs options xfs = -f -i size=2048 #强制格式化
journal max write bytes = 1073714824 #默认值1048560 #journal一次性写入的最大字节数(bytes)
journal max write entries = 10000 #默认值100 #journal一次性写入的最大记录数
journal queue max ops = 50000 #默认值50 #journal一次性最大在队列中的操作数
journal queue max bytes = 10485760000 #默认值33554432 #journal一次性最大在队列中的字节数(bytes)
osd max write size = 512 #默认值90 #OSD一次可写入的最大值(MB)
osd client message size cap = 2147483648 #默认值100 #客户端允许在内存中的最大数据(bytes)
osd deep scrub stride = 131072 #默认值524288 #在Deep Scrub时候允许读取的字节数(bytes)
osd op threads = 16 #默认值2 #并发文件系统操作数
osd disk threads = 4 #默认值1 #OSD密集型操作例如恢复和Scrubbing时的线程
osd map cache size = 1024 #默认值500 #保留OSD Map的缓存(MB)
osd map cache bl size = 128 #默认值50 #OSD进程在内存中的OSD Map缓存(MB)
osd mount options xfs = "rw,noexec,nodev,noatime,nodiratime" #默认值rw,noatime,inode64 #Ceph OSD xfs Mount选项
osd recovery op priority = 4 #默认值10 #恢复操作优先级，取值1-63，值越高占用资源越高
osd recovery max active = 10 #默认值15 #同一时间内活跃的恢复请求数
osd max backfills = 4 #默认值10 #一个OSD允许的最大backfills数
osd min pg log entries = 30000 #默认值3000 #修建PGLog是保留的最大PGLog数
osd max pg log entries = 100000 #默认值10000 #修建PGLog是保留的最大PGLog数
osd mon heartbeat interval = 40 #默认值30 #OSD ping一个monitor的时间间隔（默认30s）
ms dispatch throttle bytes = 1048576000 #默认值 104857600 #等待派遣的最大消息数
objecter inflight ops = 819200 #默认值1024 #客户端流控，允许的最大未发送io请求数，超过阀值会堵塞应用io，为0表示不受限
osd op log threshold = 50 #默认值5 #一次显示多少操作的log
osd crush chooseleaf type = 0 #默认值为1 #CRUSH规则用到chooseleaf时的bucket的类型
##############################################################
[mds]
mds cache memory limit = 1073741824#MDS元数据热缓存限制之前好多人都是使用mds_ cache_size参数进行限制,Inode count这个官方已经不推荐使用了,直接在内存中维护一组热元数据，而不需要与RADOS中的元数据池进行通信

2.1 开启ceph的后端存储bluestore

ceph 的 luminous之后bluestore已经很稳定了,以下是官方的changelog可以看到改进很多

bluestore: bluestore/NVMEDevice: accurate the latency perf counter of queue latency (pr#17435, Ziye Yang, Pan Liu)
bluestore: bluestore/NVMEDevice: convert the legacy config opt related with SPDK (pr#18502, Ziye Yang)
bluestore: bluestore/NVMEDevice: do not deference a dangling pointer (pr#19067, Kefu Chai)
bluestore: bluestore/NVMEDevice: fix the bug in write function (pr#17086, Ziye Yang, Pan Liu)
bluestore: bluestore/NVMeDevice: update NVMeDevice code due to SPDK upgrade (pr#16927, Ziye Yang)
bluestore,build/ops: bluestore,cmake: enable building bluestore without aio (pr#19017, Kefu Chai)
bluestore,build/ops: Build: create a proper WITH_BLUESTORE option (pr#18357, Alan Somers)
bluestore,build/ops: ce: change aio-max-nr to 1048576 (pr#17894, chenliuzhong)
bluestore,build/ops,tests: os: add compile option to build libblue (pr#16733, Pan Liu)
bluestore,build/ops,tests: test/fio: fix build failure caused by sequencer replacement (pr#20387, Igor Fedotov)
bluestore: ceph-bluestore-tool: better fsck/repair, bluefs-bdev-{expand,sizes} (pr#17709, Sage Weil)
bluestore: ceph-bluestore-tool: check if bdev is empty on ‘bluefs-bdev-expand’ (pr#17874, WANG Guoqin)
bluestore: ceph-bluestore-tool: link target shouldn’t ending with “n” (pr#18585, Yao Zongyou)
bluestore,common: intarith: get rid of P2* and ROUND_UP* macros (pr#21085, xie xingguo)
bluestore: comp_min_blob_size init error (pr#18318, linbing)
bluestore: config: Change bluestore_cache_kv_max to type INT64 (pr#20255, Zhi Zhang)
bluestore,core: ceph-bluestore-tool: prime-osd-dir: update symlinks instead of bailing (pr#18565, Sage Weil)
bluestore,core: common/options: bluefs_buffered_io=true by default (pr#20542, Sage Weil)
bluestore,core: os/bluestore: compensate for bad freelistmanager size/blocks metadata (issue#21089, pr#17268, Sage Weil)
bluestore,core: os/bluestore: fix data read error injection in bluestore (pr#19866, Sage Weil)
bluestore,core: os/bluestore: kv_max -> kv_min (pr#20544, Sage Weil)
bluestore,core: os/bluestore: switch default allocator to stupid; test both bitmap and stupid in qa (pr#16906, Sage Weil)
bluestore,core: src/bluestore/NVMEDevice: make all read use aio_submit (pr#17655, Ziye Yang, Pan Liu)
bluestore,core,tests: test/unittest_bluefs: check whether rmdir success (pr#15363, shiqi)
bluestore,core: tool: ceph-kvstore-tool doesn’t umount BlueStore properly (issue#21625, pr#18083, Chang Liu)
bluestore: define default value of LoglevelV only once (3 templates) (pr#20727, Matt Benjamin)
bluestore: drop unused friend class in SharedDriverQueueData (pr#16894, Pan Liu)
bluestore: fix aio_t::rval type (issue#23527, pr#21136, kungf)
bluestore: fix build on armhf (pr#20951, Kefu Chai)
bluestore: fixed compilation error when enable spdk with gcc 4.8.5 (pr#16945, Ziye Yang, Pan Liu)
bluestore: kv/RocksDBStore: extract common code to a new function (pr#16532, Pan Liu)
bluestore/NVMEDevice: code cleanup (pr#17284, Ziye Yang, Pan Liu)
bluestore: os/bluestore: add bluestore_prefer_deferred_size_hdd/ssd to tracked keys (pr#17459, xie xingguo)
bluestore: os/bluestore: add discard method for ssd’s performance (pr#14727, Taeksang Kim)
bluestore: os/bluestore: Add lat record of deferred_queued and deferred_aio_wait (pr#17015, lisali)
bluestore: os/bluestore: Add missing __func__ in dout (pr#17903, lisali)
bluestore: os/bluestore: add perf counter for allocator fragmentation (pr#21377, Igor Fedotov)
bluestore: os/bluestore: allocate entire write in one go (pr#17698, Sage Weil)
bluestore: os/bluestore: allow reconstruction of osd data dir from bluestore bdev label (pr#18256, Sage Weil)
bluestore: os/bluestore: alter the allow_eio policy regarding kernel’s error list (issue#23333, pr#21306, Radoslaw Zarzynski)
bluestore: os/bluestore: avoid excessive ops in _txc_release_alloc (pr#18854, Igor Fedotov)
bluestore: os/bluestore: avoid omit cache for remove-collection (pr#18785, Jianpeng Ma)
bluestore: os/bluestore: avoid overhead of std::function in blob_t (pr#20294, Radoslaw Zarzynski)
具体你们还是自己了解吧我在这里就不解释了哈

bluestore的诞生是为了解决filestore自身维护一套journal并同时还需要基于系统文件系统的写放大问题，并且filestore本身没有对SSD进行优化，因此bluestore相比于filestore主要做了两方面的核心工作：—>去掉journal —->针对SSD进行单独优化，直接管理裸盘(物理磁盘设备)，从理论上来讲，进一步规避了如ext4、xfs等文件系统部分的开销，BlueStore是一个全新的 OSD存储后端，通过块设备提升存储性能. 最后我用大白话说就是———–》》》》》》》》》》》》》》

BlueStore可使数据对象无需任何文件系统的接口，就可以直接存储在物理块设备上，所以，BlueStore可以极大的提升Ceph存储系统性能

具体的开启流程以及bluestore资料大家可以谷歌(默认在L+版本以后都是默认开启的，bluestore本身也包含一些调休优参数，后面我会更新文章，本人也是刚刚接触,进一步探索当中)

2.2. PG Number

PG和PGP数量一定要根据OSD的数量进行调整，计算公式如下，但是最后算出的结果一定要接近或者等于一个2的指数。

Total PGs = (Total_number_of_OSD * 100) / max_replication_count

例如15个OSD，副本数为3的情况下，根据公式计算的结果应该为500，最接近512，所以需要设定该pool(volumes)的pg_num和pgp_num都为512.

技术引申:

如果你想优化的话就需要先了解ceph读写的交互过程

cephfs kernel driver client write 一次写需要的主要步骤有：

（1） 一次client 到mds端得open 操作获取元数据，如果local 已经有 cap的缓存了就本地取

（2） 每个IO，client 端都需要加 inode_lock 信号量锁；

（3） client 发起读 MDScaps，如果local 已经有 caps的缓存了就本地取，否则就到MDS 端取，MDS 端加 rdlocksSimpleLock锁 返回 ATTR

（4） 每个direct io，client端都会run spin_lock锁一次

（5） client 端发起写OSD端，server 端写数据到OSD

（6） client inode_unlock 解信号量锁cephFS每次IO请求都需要加好几把锁，对比RBD，cephfs client 写多了：

• 一次ceph_open 到mds端获取元数据的操作，本地有caps cache 就本地取
• 每个IO都需要run一次信号量锁，这个对性能影响较大
• 每个direct IO 都 run 一次snap 处理的 spin_lock锁，这个对性能影响较大
• 每个IO 都需要获取一次caps，本地有capscache 就本地取，否则就到MDS 端多读一次元数据，
• 如果需要到MDS端读取元数据，那么执行SimpleLock 锁 最少4次，这个对性能影响较大

另外 direct IO 下盘，每个OBJECT 是按顺序下发再返回，3副本的话需要6次写才能完成返回，因此性能影响较大。

2.性能问题解决方案(结合自己搜索的资料以及个人经验)

CephFS的性能不如意问题主要是其本身的架构决定的，并且将内核态的cephfs 客户端改成ceph-fuse用户态客户端性能还有 20%~30%的下降，如果去改这个架构来提升性能，粗略的评估下来是性价比不划算。就ceph目前的架构设计来说，合理的提升性能的思路及方向有：

（1） 调整相应的参数，这个效果有点用但是不大；

（2） 上DPDK 网卡驱动用户态化；

（3） 将MDS的元数据放在NVDIMM cache或者 SATA/SAS/PCIe/NVMe SSD, 3DXPOINT里

（4） 上SPDK 方案

（5） 采用 SATA/SAS/PCIe/NVMe SSD, 3DXPOINT存储数据而不是 SAS盘

（6） 增大ceph的规模scale out横向扩展

（7） 将数据3副本改为2副本 降低副本数对加快读写也有很大的作用但是前提是保证数据的安全性