ceph bluestore的db分区应该预留多大的空间

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

前言

关于bluestore的db应该预留多少空间，网上有很多资料

如果采用默认的

write_buffer_size=268435456

大小的话

那么几个rocksdb的数据等级是

L0: in memory L1: 256MB L2: 2.56 GB L3: 25.6 GB L4: 256 GB

设置L4那么大的ssd可以给一个osd使用有点不划算，那么空间一般计算就是L1+L2+L3将近30GB

这个可以参考下面的文章

https://blog.csdn.net/NewTyun/article/details/103379694

关于block.db大小调整,只需为所有Bluestore OSD保留30 GB

那么这个大小对不对，如果你直接参考30GB这个，并且按照常规的去分区来说，就会带来问题了，我们看下具体什么问题

实际测试验证

parted -s /dev/sdb mkpart primaru 1 31G

上面的命令已经放大了1GB了，但是实际上还是不行

[root@lab102 ~]# ceph daemon osd.0 perf dump|grep bluefs -A 10 "bluefs": { "gift_bytes": 0, "reclaim_bytes": 0, "db_total_bytes": 30999044096, "db_used_bytes": 3258966016, "wal_total_bytes": 1999630336, "wal_used_bytes": 501215232, "slow_total_bytes": 160000114688, "slow_used_bytes": 7837319168, "num_files": 194, "log_bytes": 10485760,

上面是我测试环境记录的值，db只使用了3.2G实际上已经开始使用slow 了,所以这个大小实际上不满足的我的预设的，这个跟parted命令分区的GB转换也存在的一定的关系

看下parted的问题

[root@lab102 ~]# parted -s /dev/sdf mkpart primary 1 1GB [root@lab102 ~]# parted -s /dev/sdf print Model: Intel RMS25CB080 (scsi) Disk /dev/sdf: 4000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 1000MB 999MB primary

可以看到上面创建1GB的时候实际上只创建了999MB，加上我指定的从1MB开始，实际上这个地方设置是按1000进制处理容量的，而对容量的需求的是真正的1024的去算的，这个地方就存在误差了

那么我们简单点处理，就是直接放大到35GB即可

parted -s /dev/sdf mkpart primary 1 35GB

按这个容量设置的，能够保证上面的L3没有先满的时候不会提前溢出了

红帽的官方的建议是留1T 40GB左右，而suse是建议db大小为64GB

https://documentation.suse.com/zh-tw/ses/6/single-html/ses-deployment/index.html#:~:text=如需BlueStore 的詳細,使用單獨的分割區。

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4/html/administration_guide/osd-bluestore

如果没有调整write_buffer_size的情况下，建议是35GB，40GB或者64GB，这个都存在一些放大设置，如果磁盘空间足够的情况下，多分一点也没什么关系的，尽量避免转换不正确带来的未知的降速

WAL大小，suse建议是4GB的

测试模型构建

准备一个4TB的sata盘，准备一个db分区，准备一个wal分区(测试环境为2GB)

db分区设置为你需要的大小，上面的环境当中，我测试了db 30GB和35GB两组大小的情况

设置35GB写入600万文件的时候osd的db情况如下：

ceph daemon osd.0 perf dump|grep bluefs -A 10 "bluefs": { "gift_bytes": 0, "reclaim_bytes": 0, "db_total_bytes": 34999361536, "db_used_bytes": 10392428544, "wal_total_bytes": 1999630336, "wal_used_bytes": 492826624, "slow_total_bytes": 160000114688, "slow_used_bytes": 0, "num_files": 177, "log_bytes": 3944448,

创建osd的命令

ceph-deploy osd create --data /dev/sdc1 --block-db /dev/sdb1 --block-wal /dev/sdb2 lab102

创建一个rgw网关

然后用cosbench往网关打数据

200个worker，64KB的文件，写入600万文件

测试一轮的时间大概为2小时就可以复现上面的情况，测试过程还带出了另外的一个问题

rgw_dynamic_resharding = true

这个动态分片过程中会有一定的概率阻塞住请求的，通过cosbench里面的压测图形也可以看到分片后的性能比没分片是好很多的，所以如果抢时间的话