• 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 >

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   找到函数加偏移

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31

    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]}'



    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20

    线程死锁

    ps -ef | grep osd :  找到osd的pid

pstree -p pid

gdb attach pid / tid
bt---> frame  num  ----> p 关于锁的相关变量  ---> 查看各个锁的owner
切换至另一个线程，重复上面的步骤多次分析，画出图


    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    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 
    

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72

    2. PG

    PG 无法达到 CLEAN 状态
创建一个新集群后，PG 的状态一直处于 active ， active + remapped 或 active + degraded 状态， 而无法达到 active + clean 状态 ，那很可能是你的配置有问题。

你可能需要检查下集群中有关 Pool 、 PG 和 CRUSH 的配置项，做以适当的调整。

一般来说，你的集群中需要多于 1 个 OSD，并且存储池的 size 要大于 1 副本。

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    你可以用下列命令显式地列出卡住的 PGs：
  ceph pg dump_stuck stale
  ceph pg dump_stuck inactive
  ceph pg dump_stuck unclean
  
  卡在 stale 状态的 PG 通过重启 ceph-osd 进程通常可以修复；
  卡在 inactive 状态的 PG 通常是互联问题；
  卡在 unclean 状态的 PG 通常是由于某些原因阻止了恢复的完成，像未找到的对象（参见 未找到的对象 ）。

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    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}



    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    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 ）了，让集群尽力完成副本拷贝。

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    未找到的对象，某几种失败相组合，可能导致 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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73
    • 74
    • 75
    • 76
    • 77
    • 78
    • 79
    • 80
    • 81
    • 82
    • 83
    • 84
    • 85
    • 86
    • 87
    • 88
    • 89
    • 90
    • 91
    • 92
    • 93
    • 94
    • 95
    • 96
    • 97
    • 98
    • 99
    • 100
    • 101
    • 102
    • 103
    • 104
    • 105
    • 106
    • 107
    • 108
    • 109
    • 110
    • 111
    • 112
    • 113
    • 114
    • 115
    • 116
    • 117
    • 118
    • 119
    • 120
    • 121
    • 122
    • 123
    • 124
    • 125
    • 126
    • 127
    • 128
    • 129
    • 130
    • 131
    • 132
    • 133
    • 134
    • 135
    • 136
    • 137
    • 138
    • 139
    • 140
    • 141
    • 142
    • 143
    • 144
    • 145
    • 146
    • 147
    • 148
    • 149
    • 150
    • 151
    • 152
    • 153
    • 154
    • 155
    • 156
    • 157
    • 158
    • 159
    • 160
    • 161
    • 162
    • 163
    • 164
    • 165
    • 166
    • 167
    • 168
    • 169
    • 170
    • 171
    • 172
    • 173
    • 174
    • 175
    • 176
    • 177
    • 178
    • 179
    • 180
    • 181
    • 182
    • 183
    • 184
    • 185
    • 186
    • 187
    • 188
    • 189
    • 190
    • 191
    • 192
    • 193
    • 194
    • 195
    • 196
    • 197
    • 198
    • 199
    • 200
    • 201
    • 202
    • 203
    • 204
    • 205
    • 206
    • 207
    • 208

    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
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    1.查看ceph集群配置信息
    ceph daemon /var/run/ceph/ceph-mon.$(hostname -s).asok config show

    • 1
    2.修改ceph.conf文件，并推送
    //在部署节点cent用户下切换到ceph目录下，修改ceph.conf文件，将新配置推送至全部的ceph节点
ceph-deploy  --overwrite-conf config push dlp node1 node2 node3

    • 1
    • 2
    3.检查仲裁状态
    检查仲裁状态，查看mon添加是否成功
ceph quorum_status --format json-pretty

    • 1
    • 2
    4. 列式pool列表
    ceph osd lspools

    • 1
    5. 列示pool详细信息
    ceph osd dump |grep pool

    • 1
    6. 检查pool的副本数
    ceph osd dump|grep -i size

    • 1
    7. 创建pool
    ceph osd pool create pooltest 128

    • 1
    8. 删除pool
    ceph osd pool delete data
ceph osd pool delete data data  --yes-i-really-really-mean-it

    • 1
    • 2
    9. 设置pool副本数
    ceph osd pool get data size
ceph osd pool set data size 3

    • 1
    • 2
    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

    • 1
    • 2
    • 3
    11. 重命名pool
    ceph osd pool rename data date

    • 1
    12. 获取现有的PG数和PGP数值
    ceph osd pool get data pg_num
ceph osd pool get data pgp_num

    • 1
    • 2
    13. 修改存储池的PG和PGP
    ceph osd pool set data pg_num = 1
ceph osd pool set data pgp_num = 1

    • 1
    • 2
    14. watch
     watch可以帮你监测一个命令的运行结果，来监测你想要的一切命令的结果变化watch -n 1设置每隔一秒 来监测你想要执行的命令；-d 显示变化情况；
     watch -n 1 ceph -s ;每隔一秒监视ceph -s的运行结果
     watch -n 1 -d  ”命令“ 可以监视你想要看到的某个数值的变化

    • 1
    • 2
    • 3
    15. 挂盘失败重新激活
     ceph-disk activate-all

    • 1
    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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    17. osd 与PG查找

    osd --> pg: 通过 osd 查找 pg

    ceph pg ls-by-osd osd.{osdid}

    • 1

    pg --> osd: 通过 pg 查找 osd

    ceph pg map {pgid}

    • 1

    pg --> pool: 通过 pg 查找 pool

    ceph pg dump | grep "^{pgid}\."

    • 1
    pool --> pg: 通过 pool 查找 pg
ceph pg ls-by-pool {poolname}
ceph pg ls {poolid}

    • 1
    • 2
    • 3
    object --> osd: 通过 object 查找 osd
ceph osd map {poolname} {objectname}

    • 1
    • 2
    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；如果存在该文件，则不会自动拉起，需要手动拉起

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    19.删卷和删池
    注意：删池前需要先删卷。先在主节点上执行下面命令删卷

sudo -u postgres psql -c "delete from op_blk_lunmng" calamari 
supervisorctl restart all 
然后在handy页面删除池（pool)，最后新建池和新建卷

    • 1
    • 2
    • 3
    • 4
    • 5
    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)

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    处理方式

    [root@test]#/etc/init.d/syslog restart 
或者
[root@test]#/etc/init.d/syslog stop 
[root@test]#/etc/init.d/syslog start

    • 1
    • 2
    • 3
    • 4
    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

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    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) 

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    22. 模拟读写

    bench

    rados bench -p    -b  -t --no-cleanup
：池名称
：测试所持续的秒数
：操作模式，write：写，seq：顺序读；rand：随机读
-b：块大小，即一次写入的数据量大小,默认为4MB
-t：线程数量,默认为16
--no-cleanup 表示测试完成后不删除测试用数据。在做读测试之前，需要使用该参数来运行一遍写测试来产生测试数据，在全部测试结束后可以运行 rados -p  cleanup 来清理所有测试数据。默认是会被清空
例子：rados bench 300 -b 4M -t 16 write --no-cleanup -p storage-cold  


    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    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 

    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15

    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 以上 


    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
  • 相关阅读:
    tailwindcss 如何在 uniapp 中使用
    Mysqld之MHA高可用
    高效、透明-企事业数字化的采购管理系统(源程序源代码)
    深度学习从入门到入土
    深入浅出Docker：Java开发者的快速上手指南
    C++ Qt高级开发视频教程
    关于大模型训练微调的几个概念
    如何使用代码来构造HTTP请求？
    2022/8/15 考试总结
    go module 导入本地包
  • 原文地址：https://blog.csdn.net/Kiris_king/article/details/128093514