Ceph-MDS技术问题分析.docx

?

?

CephMDS问题分析

?

?

1.问题背景

1.1客户端缓存问题

$ceph-s

healthHEALTH_WARN

mds0:Clienxxf-online00.gz01failingtorespondtocachepressure

官方解释

消息:“Clientnamefailingtorespondtocachepressure”

代码:MDS_HEALTH_CLIENT_RECALL,MDS_HEALTH_CLIENT_RECALL_MANY

描述:

客户端有各自的元数据缓存，客户端缓存中的条目（比如索引节点）也会存在于MDS缓存中，所以当MDS需要削减其缓存时（保持在mds_cache_size以下），它也会发消息给客户端让它们削减自己的缓存。如果有客户端没响应或者有缺陷，就会妨碍MDS将缓存保持在mds_cache_size以下，MDS就有可能耗尽内存而后崩溃。如果某个客户端的响应时间超过了mds_recall_state_timeout（默认为60s），这条消息就会出现。

1.2服务端内存不释放

同上参考1.1客户端缓存问题

1.3mdssession的inode过多

客户端session的inode太多，导致内存很高，从而也导致主从mds切换加载inode慢，严重影响服务的可用性。

1.4mds夯住问题或慢查询

客户端搜索遍历查找文件（不可控)

session的inode太大导致mds负载过高

日志级别开的太大，从而导致mds负载高

2.1组件通信流程图

l4bnrrddva

1、Client–MDS

元数据操作和capalities

2、Client–OSD

数据IO

3、Client–Monitor

认证，集群map信息等

4、MDS–Monitor

心跳，集群map信息等

5、MDS–OSD

元数据IO

6、Monitor–OSD

心跳，集群map信息等

2.2查看客户端session

$ceph--admin-daemon/var/run/ceph/ceph-mds.ceph-xxxx-osd02.py.asoksessionls

[

{

id:5122511,

num_leases:0,

num_caps:655,

state:open,

replay_requests:0,

completed_requests:1,

reconnecting:false,

inst:client.5122511:0\/2026289820,

client_metadata:{

ceph_sha1:b1e0532418e4631af01acbc0cedd426f1905f4af,

ceph_version:cephversion0.94.10(b1e0532418e4631af01acbc0cedd426f1905f4af),

entity_id:log_xxx_cephfs,

hostname:ceph-test-osd02,

mount_point:\/mnt\/log

}

}

]

说明：

1、id：client唯一id

2、num_caps：client获取的caps

3、inst：client端的ip和端口链接信息

4、ceph_version：client端的ceph-fuse版本，若使用kernelclient，则为kernel_version

5、hostname：client端的主机名

6、mount_point：client在主机上对应的mountpoint

7、pid：client端ceph-fuse进程的pid

2.3查看客户端的inode数量

跟踪代码发现session里面的num_caps就是统计的客户端的inode数量,大概统计了下已经打开的inode数量在400w左右。

1kegyzfnt5y

总结：

可以查看客户端的session信息，包含host、mount、inode等信息

可以统计所有客户端session的inode数量。

2.4尝试mds主从切换

2.4.1执行过程如下

2018-04-2719:24:03.9233497f53015d77001mds.0.2738handle_m