ceph debug
萧远
段错误
编译：
先把代码会退到测试的版本，然后使用 ./auto_build.sh -d 参数在编译机上编译出debug版本的包，在按上面指令到bin目录下
执行nm那个命令解析出函数名就可以看了
[root@Compiler120 bi///
0000000000959870 W MMonMgrReport::encode_payload(unsigned long)
0000000000959af0 W MPGStats::encode_payload(unsigned long)
[root@Compiler120 bin]# objdump -ldS --start-address=0x959770 --stop-address=0x95a5f4 ceph-mon > msx
[root@Compiler120 bin]# addr2line -e ceph-mon -f 0x95A2F4
decode_raw<ceph_le<short unsigned int> >
src/include/encoding.h:78
nm算出函数的地址，然后计算偏移后的地址，最后可以用addr2line命令查看函数信息。
或者 objdump -ldS查看范围内的函数堆栈，并生成bb文件，最后vim打开查看
grep -rn "OnRecoveryReadComplete" ./
find ./ -name xx.cc.o
objdump -Sl ./build/src/osd/CMakeFiles/osd.dir/xx.cc.o > xxxre
用vim 打开后 输入 :%!c++filt 找到函数加偏移
PerfCount
onestor-cli perf -h
onestor-cli perf -t open -d 192.168.122.18
onestor-cli perf -t show -d 192.168.122.18
onestor-cli perf -t close -d 192.168.122.18
sudo onestor-cli perf -m all -t open
sudo onestor-cli perf -m all -t show >perflcl
sudo onestor-cli perf -m all -t close
perf record --call-graph dwarf -t tid -o xxx.data sleep 15 抓线程
perf record --call-graph dwarf -p pid -o xxx.data sleep 15 抓进程
perf script -i xxx.data > xxx.unfolded
/opt/flamegraph/stackcollapse-perf.pl xxx.unfolded > xxx.folded
/opt/flamegraph/flamegraph.pl xxx.folded > xxx.html
socket 状态统计 ： netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a,S[a]}'
线程死锁
ps -ef | grep osd : 找到osd的pid
pstree -p pid
gdb attach pid / tid
bt---> frame num ----> p 关于锁的相关变量 ---> 查看各个锁的owner
切换至另一个线程，重复上面的步骤多次分析，画出图
ceph
1. osd
cat /sys/block/sda/queue/rotational 返回0：SSD盘 返回1：SATA盘
lsscsi
ceph osd tree：查看osd的状态和编号以及分布情况
ceph osd find osd.0 :查看osd.0节点ip和主机名
ceph osd map {poolname} {object-name} : 要定位对象，只需要对象名和存储池名字
ceph osd df //查看osd的使用信息
ceph osd dump //osd的map信息
ceph osd metadata 0//查看osd元数据的详细信息
ceph osd pool ls detail //查看池的的详细信息
ceph osd pool stats //查看池的IO情况
ps -ef | grep osd/dse/ceph-mon: 查看进程是否存在
killall -9 ceph-osd
kill -9 进程id
ceph health 查看集群健康状态
ceph mon stat 查看mon的状态信息
ceph pg ls-by-osd 9 | awk '{print $1}' > osd.9
ceph osd pg-upmap-items 6559.3d 9 17 //将pg 6559.3d从9迁到17
osdmaptool ./om --upmap-pool thinpool1 --upmap 33 > 44
ceph osd getmap -o om
ceph osd df | sort -nk 8 //对第8列排序
iostat -x 1
[root@host21 pg]# ceph pg dump | grep "65542." | awk '{print$2}' | less
[root@host21 pg]# ceph pg dump | grep "65542." | awk '{print$1 $2}' | less
[root@host21 pg]# ceph pg dump | grep "65542." | awk '{print$1" "$2}' | less
[root@host21 pg]# ceph pg dump | grep "65542." | awk '{print$1" "$2}' | less
ceph osd pool ls detail
ceph osd getmap –o om //获取当前osdmap
ceph osd getmap epoch –o om //获取epoch 版本号时的 osdmap
osdmaptool --print om
osdmaptool om --dump
ceph osd getmap -o om
osdmaptool om --upmap-pool p01 --upmap 1 > 2
ceph-dencoder import om type OSDMap decode dump_json
数据均衡：
src/ceph-mon-pg-check.sh
vim /etc/crow.d/ceph_crow
/var/log/storage/pg
数据重构
1、 osd_recover_interval_flag ---这个默认值是1， 改成0，pg之间recover将不等待
2、osd_recovery_max_active 这个是osd_recovery 的并发数，默认1，可开到11，会影响业务
3、osd-recovery-sleep
4、mon_osd_expect_recovery_bw ：重构带宽，默认6 ， 可调大
mon_osd_expect_recovery_iops 默认48
5、osd_max_backfills ：一个osd上最多能同时有多少个PG一起backfill
2. PG
PG 无法达到 CLEAN 状态
创建一个新集群后，PG 的状态一直处于 active ， active + remapped 或 active + degraded 状态， 而无法达到 active + clean 状态 ，那很可能是你的配置有问题。
你可能需要检查下集群中有关 Pool 、 PG 和 CRUSH 的配置项，做以适当的调整。
一般来说，你的集群中需要多于 1 个 OSD，并且存储池的 size 要大于 1 副本。
你可以用下列命令显式地列出卡住的 PGs：
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
卡在 stale 状态的 PG 通过重启 ceph-osd 进程通常可以修复；
卡在 inactive 状态的 PG 通常是互联问题；
卡在 unclean 状态的 PG 通常是由于某些原因阻止了恢复的完成，像未找到的对象（参见 未找到的对象 ）。
pg一直处于creating
发现有pg一直处于creating状态时有两种处理方法：
方法一：重启全部osd（如果不起作用，采用第二种）
方法二：通过pg-temp处理pg creating状态，具体方法：
1）过滤处于creating状态的pg
ceph pg dump | grep creating
2）查看pg对应的osd列表
ceph pg map $pgid
3）使用pg-temp修复creating状态
ceph osd pg-temp $pgid {up的osd列表}
例如：
pg：15.1e8a
pg对应的osd 列表 {119,61,105}
使用下面的命令：
ceph osd pg-temp 15.1e8a {119,61,105}
ceph health detail
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
ceph pg 0.5 query
{ "state": "down+peering",
...
"recovery_state": [
{ "name": "Started\/Primary\/Peering\/GetInfo",
"enter_time": "2012-03-06 14:40:16.169679",
"requested_info_from": []},
{ "name": "Started\/Primary\/Peering",
"enter_time": "2012-03-06 14:40:16.169659",
"probing_osds": [
0,
1],
"blocked": "peering is blocked due to down osds",
"down_osds_we_would_probe": [
1],
"peering_blocked_by": [
{ "osd": 1,
"current_lost_at": 0,
"comment": "starting or marking this osd lost may let us proceed"}]},
{ "name": "Started",
"enter_time": "2012-03-06 14:40:16.169513"}
]
}
recovery_state 段告诉我们互联过程因 ceph-osd 进程挂了而被阻塞，本例是 osd.1 挂了，启动这个进程应该就可以恢复。
或者，如果 osd.1 发生了灾难性的失败（如硬盘损坏），我们可以告诉集群它丢失（ lost ）了，让集群尽力完成副本拷贝。
未找到的对象，某几种失败相组合，可能导致 Ceph 抱怨有找不到（ unfound ）的对象：
ceph health detail
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
pg 2.4 is active+degraded, 78 unfound
这意味着存储集群知道一些对象（或者存在对象的较新副本）存在，却没有找到它们的副本。下例展示了这种情况是如何发生的，一个 PG 的数据存储在 ceph-osd 1 和 2 上：
```
1 挂了
2 独自处理一些写动作
1 起来了
1 和 2 重新互联， 1 上面丢失的对象加入队列准备恢复
新对象还未拷贝完， 2 挂了
这时， 1 知道这些对象存在，但是活着的 ceph-osd 都没有这些副本。这种情况下，读写这些对象的 IO 就会被阻塞，集群只能指望 down 掉的节点尽早恢复。这样处理是假设比直接给用户返回一个 IO 错误要好一些。
```
首先，你应该确认哪些对象找不到了：
```
ceph pg 2.4 list_missing [starting offset, in json]
{ "offset": { "oid": "",
"key": "",
"snapid": 0,
"hash": 0,
"max": 0},
"num_missing": 0,
"num_unfound": 0,
"objects": [
{ "oid": "object 1",
"key": "",
"hash": 0,
"max": 0 },
...
],
"more": 0}
```
如果在一次查询里列出的对象太多， more 这个字段将为 true ，你就可以查询更多。
其次，你可以找出哪些 OSD 上探测到、或可能包含数据：
ceph pg 2.4 query
"recovery_state": [
{ "name": "Started\/Primary\/Active",
"enter_time": "2012-03-06 15:15:46.713212",
"might_have_unfound": [
{ "osd": 1,
"status": "osd is down"}]},
本例中，集群知道 osd.1 可能有数据，但它挂了（ down ）。所有可能的状态有：
```
已经探测到了
在查询
OSD 挂了
尚未查询
有时候集群要花一些时间来查询可能的位置。
```
还有一种可能性，对象存在于其它位置却未被列出。例如，集群里的一个 ceph-osd 停止且被剔出集群，然后集群完全恢复了；后来一系列的失败导致了未找到的对象，它也不会觉得早已死亡的 ceph-osd 上仍可能包含这些对象。（这种情况几乎不太可能发生）。
如果所有可能的位置都查询过了但仍有对象丢失，那就得放弃丢失的对象了。这仍可能是罕见的失败组合导致的，集群在写操作恢复后，未能得知写入是否已执行。以下命令把未找到的（ unfound ）对象标记为丢失（ lost ）。
```
ceph pg 2.5 mark_unfound_lost revert|delete
上述最后一个参数告诉集群应如何处理丢失的对象。
delete 选项将导致完全删除它们。
revert 选项（纠删码存储池不可用）会回滚到前一个版本或者（如果它是新对象的话）删除它。要慎用，它可能迷惑那些期望对象存在的应用程序。
```
3.5 无家可归的 PG
拥有 PG 拷贝的 OSD 可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor 也就不会收到那些 PG 的状态更新了。为检测这种情况，monitor 会把任何主 OSD 失败的 PG 标记为 stale （不新鲜），例如：
```
ceph health
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
可以找出哪些 PG 是 stale 状态，和存储这些归置组的最新 OSD ，命令如下：
ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
如果想使 PG 2.5 重新上线，例如，上面的输出告诉我们它最后由 osd.0 和 osd.2 管理，重启这些 ceph-osd 将恢复之（可以假定还有其它的很多 PG 也会进行恢复 ）。
```
3.6 只有几个 OSD 接收数据
如果你的集群有很多节点，但只有其中几个接收数据，检查下存储池里的 PG 数量。因为 PG 是映射到多个 OSD 的，较少的 PG 将不能均衡地分布于整个集群。试着创建个新存储池，设置 PG 数量是 OSD 数量的若干倍。更详细的信息可以参考 Ceph 官方文档 —— Placement Groups 。
3.7 不能写入数据
如果你的集群已启动，但一些 OSD 没起来，导致不能写入数据，确认下运行的 OSD 数量满足 PG 要求的最低 OSD 数。如果不能满足， Ceph 就不会允许你写入数据，因为 Ceph 不能保证复制能如愿进行。这个最低 OSD 个数是由参数 osd pool default min size 限定的。
3.8 PG 不一致
如果收到 active + clean + inconsistent 这样的状态，很可能是由于在对 PG 做擦洗（ scrubbing ）时发生了错误。如果是由于磁盘错误导致的不一致，请检查磁盘，如果磁盘有损坏，可能需要将这个磁盘对应的 OSD 踢出集群，然后进行更换。生产环境中遇到过不一致的问题，就是由于磁盘坏道导致的。
当集群中出现 PG 不一致的问题时，执行 ceph -s 命令会出现下面的信息：
```
root@mon:~# ceph -s
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3
health HEALTH_ERR
1 pgs inconsistent
1 scrub errors
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0}
election epoch 796, quorum 0 osd1
osdmap e1079: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v312153: 384 pgs, 6 pools, 1148 MB data, 311 objects
3604 MB used, 73154 MB / 76759 MB avail
383 active+clean
1 active+clean+inconsistent
```
1、查找处于 inconsistent 状态的问题 PG ：
```
root@mon:~# ceph health detail
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 9.14 is active+clean+inconsistent, acting [1,2,0]
1 scrub errors
这个有问题的 PG 分布在 osd.1 、 osd.2 和 osd.0 上，其中 osd.1 是主 OSD。
```
2、去主 OSD（ osd.1 ）的日志中查找不一致的具体对象 。
```
root@osd0:~# grep -Hn 'ERR' /var/log/ceph/ceph-osd.1.log
/var/log/ceph/ceph-osd.1.log:30:2016-11-10 13:49:07.848804 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 shard 0: soid 9:29b4ad99:::rbd_data.1349f035c101d9.0000000000000001:head missing attr _
/var/log/ceph/ceph-osd.1.log:31:2016-11-10 13:49:07.849803 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 scrub 0 missing, 1 inconsistent objects
/var/log/ceph/ceph-osd.1.log:32:2016-11-10 13:49:07.849824 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 scrub 1 errors
从日志中可以知道，是 rbd_data.1349f035c101d9.0000000000000001 这个对象的属性 _ 丢失了，所以在 scrub 的过程中产生了 error
```
3、执行 ceph pg repair 命令修复问题 PG 。
```
root@mon:~# ceph pg repair 9.14
instructing pg 9.14 on osd.1 to repair
```
4、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
```
root@mon:~# ceph -s
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3
health HEALTH_OK
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0}
election epoch 796, quorum 0 osd1
osdmap e1079: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v312171: 384 pgs, 6 pools, 1148 MB data, 311 objects
3604 MB used, 73154 MB / 76759 MB avail
384 active+clean
```
osd.1 的日志里也提示修复成功：
2016-11-10 14:04:31.732640 7f628c5e6700 0 log_channel(cluster) log [INF] : 9.14 repair starts
2016-11-10 14:04:31.827951 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 shard 0: soid 9:29b4ad99:::rbd_data.1349f035c101d9.0000000000000001:head missing attr _
2016-11-10 14:04:31.828117 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 repair 0 missing, 1 inconsistent objects
2016-11-10 14:04:31.828273 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 repair 1 errors, 1 fixed
如果经过前面的步骤，Ceph 仍没有达到 HEALTH_OK 状态，可以尝试用下面这种方式进行修复。
1、停掉不一致的 object 所属的 osd 。
stop ceph-osd id=xxx
2、刷新该 osd 的日志。
ceph-osd -i xx --flush-journal
3、将不一致的 object 移除。
mv /var/lib/ceph/osd/ceph-{osd-id}/current/{pg.id}_head/ rbd\\udata.xxx /home
4、重新启动该 osd 。
start ceph-osd id=xx
5、重新执行修复命令。
ceph pg repair {pg_id}
6、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
```
3.9 Too Many/Few PGs per OSD
有时候，我们在 ceph -s 的输出中可以看到如下的告警信息：
root@node241:~# ceph -s
cluster 3b37db44-f401-4409-b3bb-75585d21adfe
health HEALTH_WARN
too many PGs per OSD (652 > max 300)
monmap e1: 1 mons at {node241=192.168.2.41:6789/0}
election epoch 1, quorum 0 node241
osdmap e408: 5 osds: 5 up, 5 in
pgmap v23049: 1088 pgs, 16 pools, 256 MB data, 2889 objects
6100 MB used, 473 GB / 479 GB avail
1088 active+clean
```
ref https://lihaijing.gitbooks.io/ceph-handbook/content/Troubleshooting/troubleshooting_pg.html
3. 常用命令
ceph engine dump:
ceph -v //查看ceph的版本
ceph -s //查看集群的状态
ceph -w //监控集群的实时更改
ceph health //查看集群是否健康
ceph time-sync-status //查看mon节点的时间同步情况
ceph pg dump //查看pg的详细信息
ceph --show-config //查看默认配置
cd /var/lib/ceph/shell watch-maintaining.sh 反拉起脚本
cd /var/log/ceph
cd /var/log/storage/backup/ceph
vim /etc/ceph/ceph.conf
zgrep -a "ms_fast_dispatch" ceph.*.gz | zgrep 798522
sudo ceph daemon osd.0 config show | grep debug_osd
ceph daemon osd.2 config get debug_ms 查看日志等级
ceph daemon osd.2 config set debug_m 5 设置某个OSD节点2 的日志等级 为5
/var/log/storage/backup/system 查看历史心跳
销毁集群：
切换到root用户，执行
ssh-keygen
sudo ssh-copy-id SDS_Admin@182.100.215.128 （node ip）
or （手动把 SDS_ADMIN/.id_rsa.pub copy到 ~/root/authoried_keys文件里面手动免密）
onestor-cli destroy --host 182.100.215.128 --yes-i-really-really-mean-it 此时需要输入密码：Admin@stor，输入完之后开始卸载
du --max-depth=1|sort -rn 查找当前目录使用情况并进行排列
df - TH查看磁盘状态
lsblk 查看分区
1.查看ceph集群配置信息
ceph daemon /var/run/ceph/ceph-mon.$(hostname -s).asok config show
2.修改ceph.conf文件，并推送
//在部署节点cent用户下切换到ceph目录下，修改ceph.conf文件，将新配置推送至全部的ceph节点
ceph-deploy --overwrite-conf config push dlp node1 node2 node3
3.检查仲裁状态
检查仲裁状态，查看mon添加是否成功
ceph quorum_status --format json-pretty
4. 列式pool列表
ceph osd lspools
5. 列示pool详细信息
ceph osd dump |grep pool
6. 检查pool的副本数
ceph osd dump|grep -i size
7. 创建pool
ceph osd pool create pooltest 128
8. 删除pool
ceph osd pool delete data
ceph osd pool delete data data --yes-i-really-really-mean-it
9. 设置pool副本数
ceph osd pool get data size
ceph osd pool set data size 3
10. 设置pool配额
ceph osd pool set-quota data max_objects 100 #最大100个对象
ceph osd pool set-quota data max_bytes $((10 * 1024 * 1024 * 1024)) #容量大小最大为10G
11. 重命名pool
ceph osd pool rename data date
12. 获取现有的PG数和PGP数值
ceph osd pool get data pg_num
ceph osd pool get data pgp_num
13. 修改存储池的PG和PGP
ceph osd pool set data pg_num = 1
ceph osd pool set data pgp_num = 1
14. watch
watch可以帮你监测一个命令的运行结果，来监测你想要的一切命令的结果变化watch -n 1设置每隔一秒 来监测你想要执行的命令；-d 显示变化情况；
watch -n 1 ceph -s ;每隔一秒监视ceph -s的运行结果
watch -n 1 -d ”命令“ 可以监视你想要看到的某个数值的变化
15. 挂盘失败重新激活
ceph-disk activate-all
16. 修改日志打印级别
方法1：vim /etc/ceph/ceph.conf 后，增加debug_bluefs = 5，否则就按配置文件里默认等级打印。注意：这种重启进程也会生效。
方法2：注意：该方式只是临时生效，重启后便会失效。
ceph tell osd.* injectargs --debug_bluefs=5 (也可以指定某个osd，也可以改成其他模块的打印)
ceph daemon osd.2 config set debug_osd=3
ceph daemon osd.5 config show | grep debug_bluefs
"debug_bluefs": "1/1",
有时候开了打印，又不需要太多打印，可以
ceph -s --debug_ms=0
17. osd 与PG查找
osd --> pg: 通过 osd 查找 pg
ceph pg ls-by-osd osd.{osdid}
pg --> osd: 通过 pg 查找 osd
ceph pg map {pgid}
pg --> pool: 通过 pg 查找 pool
ceph pg dump | grep "^{pgid}\."
pool --> pg: 通过 pool 查找 pg
ceph pg ls-by-pool {poolname}
ceph pg ls {poolid}
object --> osd: 通过 object 查找 osd
ceph osd map {poolname} {objectname}
18.拉起
ceph osd tree 查看osd的目录树或id
ceph osd down 0 down掉一个osd硬盘0
注意：down完看一下是否真的osd进程没了 ps -ef|grep ceph-osd
osd手动拉起或停止：
systemctl restart ceph-osd.target //手动拉起全部osd
systemctl stop ceph-osd.target //手动停止一个主机上的所有osd
systemctl restart [ceph-osd@2.service](mailto:ceph-osd@2.service) //手动拉起单个osd
osd防拉起文件/var/lib/ceph/shell/watch_maintaining；如果存在该文件，则不会自动拉起，需要手动拉起
19.删卷和删池
注意：删池前需要先删卷。先在主节点上执行下面命令删卷
sudo -u postgres psql -c "delete from op_blk_lunmng" calamari
supervisorctl restart all
然后在handy页面删除池（pool)，最后新建池和新建卷
20.lsof | grep deleted
lsof | grep deleted 输出结果可以看到哪些文件还被使用，未被释放空间
//lsof: list open file
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
proftpd 3468 nobody 4r REG 8,2 1648 667033 /etc/passwd (deleted)
proftpd 3468 nobody 5r REG 8,2 615 667032 /etc/group (deleted)
syslogd 3854 root 2w REG 8,2 65521380 164531 /var/log/messages.1 (deleted)
syslogd 3854 root 3w REG 8,2 22728648 164288 /var/log/secure.1 (deleted)
syslogd 3854 root 5w REG 8,2 4247977 164316 /var/log/cron.1 (deleted)
处理方式
[root@test]#/etc/init.d/syslog restart
或者
[root@test]#/etc/init.d/syslog stop
[root@test]#/etc/init.d/syslog start
21.crushmap osdmap
ceph osd getcrushmap -o map_old_20210126 #导出map
crushtool -d map_old_20210126 -o map_old_20210126.txt #转化成可编辑格式
crushtool -c map_new.txt -o map_new #还原为map
ceph osd setcrushmap -i map_new #将map导入ceph
https://docs.ceph.com/en/latest/man/8/osdmaptool/
osd getmap -o osdmap 3739
ceph-decoder import osd.map type OSDMap decode dump_json | less
osdmaptool --print osd.map
[SDS_Admin@xfp136 ~]$ ceph osd getmap 2149 -o omap
2022-01-25 17:32:26.404466 7f1d577fe700 3102658 8 WARN 0 -- 172.16.108.136:0/1587633135 >> 172.16.108.97:6789/0 conn(0x7f1d58212d10 :60696 s=STATE_OPEN_MESSAGE_READ_FRONT pgs=9048441 cs=1 l=1).process read message front not complete, len: 36208
got osdmap epoch 2149
[SDS_Admin@xfp136 ~]$ osdmaptool --test-map-pg 65539.3e0 ./omap
osdmaptool: osdmap file './omap'
parsed '65539.3e0' -> 65539.3e0
65539.3e0 raw ([19,34,21], p19) up ([19,34,21], p19) acting ([19,34,21], p19)
22. 模拟读写
bench
rados bench -p <pool_name> <seconds> <write|seq|rand> -b <block size> -t --no-cleanup
<pool_name>：池名称
<seconds>：测试所持续的秒数
<write|seq|rand>：操作模式，write：写，seq：顺序读；rand：随机读
-b：块大小，即一次写入的数据量大小,默认为4MB
-t：线程数量,默认为16
--no-cleanup 表示测试完成后不删除测试用数据。在做读测试之前，需要使用该参数来运行一遍写测试来产生测试数据，在全部测试结束后可以运行 rados -p <pool_name> cleanup 来清理所有测试数据。默认是会被清空
例子：rados bench 300 -b 4M -t 16 write --no-cleanup -p storage-cold
FIO
filename=/dev/sdb1 测试文件名称，通常选择需要测试的盘的data目录，如/dev/rbd1
direct=1 测试过程绕过机器自带的buffer。使测试结果更真实。
rw=write测试写的IO
ioengine= libaio引擎使用libaio方式
bs=1M 单次io的块文件大小为16k
size=500G 本次的测试文件大小为5g，以每次4k的io进行测试。
numjobs=16 本次的测试线程为16.
runtime=600测试时间为600秒，如果不写则一直将500G文件分4M每次写完为止
rwmixwrite=30 在混合读写的模式下，写占30%
顺序写：
fio --name=test --rw=write --size=50G --numjobs=16 --iodepth=16 --ioengine=libaio --runtime=600 --bs=1M --direct=1 --filename=/dev/sdh
随机写 --rw=randwrite
fio --name=test --rw=randwrite --size=50G --numjobs=16 --iodepth=16 --ioengine=libaio --runtime=600 --bs=4k --direct=1 --group_reporting --filename=/dev/sdh
· 顺序读：
fio --name=test --rw=read --size=50G --numjobs=16 --iodepth=16 --ioengine=libaio --runtime=600 --bs=1M --direct=1 --group_reporting --filename=/dev/sdh
rados bench -p pool0 -b 4M -t 16 1000 write --no-cleanup
24. 提高重构速度
1、 osd_recover_interval_flag ---这个默认值是1， 改成0，pg之间recover将不等待
2、osd_recovery_max_active 这个是osd_recovery 的并发数，默认1，可开到11，会影响业务
3、osd-recovery-sleep
4、mon_osd_expect_recovery_bw ：重构带宽，默认6 ， 可调大
mon_osd_expect_recovery_iops 默认48
5、osd_max_backfills ：一个osd上最多能同时有多少个PG一起backfill
======== scrub 的 ==========
1、osd_max_scrubs
2、osd_scrub_sleep scrub时间间隔，默认6， 可改成0或者1.
3、osd_scrub_chunk_max 一次scrub 最大chunk数，默认1. 可改大 25或者更高
osd_scrub_chunk_min 默认1 可改5 以上
类似资料：