前言
關於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，那么預留的空間差不多需要翻一倍的
所以參數的調整，一定要實測