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
这个可以参考下面的文章
关于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里面的压测图形也可以看到分片后的性能比没分片是好很多的，所以如果抢时间的话
最好是关闭动态分片，设置好需要的分片数目
测试完需要改db的时候，直接删存储池，然后重新创建即可，推掉的操作也很快的
总结
网上的文章都是用来参考的，实际是一定需要去复测验证的，一般分享的文章也不会细化到一个parted的命令也记录，只会从原理上面出发去分析，并且环境调整了什么参数，都是不同的结果的，比如上面的
write_buffer_size如果调整到512MB，那么预留的空间差不多需要翻一倍的
所以参数的调整，一定要实测
