mds的cpu占用问题分析以及解决办法
前言
mds是ceph里面处理文件接口的组件，一旦使用文件系统，不可避免的会出现一种场景就是目录很多，目录里面的文件很多，而mds是一个单进程的组件，现在虽然有了muti mds，但稳定的使用的大部分场景还是单acitve mds的
这就会出现一种情况，一旦一个目录里面有很多文件的时候，去查询这个目录里的文件就会在当前目录做一次遍历，这个需要一个比较长的时间，如果能比较好的缓存文件信息，也能避免一些过载情况，本篇讲述的是内核客户端正常，而export nfs后mds的负载长时间过高的情况
问题复现
准备测试数据,准备好监控环境
监控mds cpu占用
pidstat -u 1 -p 27076 > /tmp/mds.cpu.log
UserParameter=mds.cpu,cat /tmp/mds.cpu.log|tail -n 1|grep -v Average| awk '{print $8}'
整个测试避免屏幕的打印影响时间统计,把输出需要重定向
测试一：
内核客户端写入10000文件查看时间以及cpu占用
[root@nfsserver kc10000]# time seq 10000|xargs -i dd if=/dev/zero of=a{} bs=1K count=1 2>/dev/null
real 0m30.121s
user 0m1.901s
sys 0m10.420s
测试二：
内核客户端写入20000文件查看时间以及cpu占用
[root@nfsserver kc20000]# time seq 20000|xargs -i dd if=/dev/zero of=a{} bs=1K count=1 2>/dev/null
real 1m38.233s
user 0m3.761s
sys 0m21.510s
测试三：
内核客户端写入40000文件查看时间以及cpu占用
[root@nfsserver kc40000]# time seq 40000|xargs -i dd if=/dev/zero of=a{} bs=1K count=1 2>/dev/null
real 2m55.261s
user 0m7.699s
sys 0m42.410s
测试4：
内核客户端列目录10000文件，第一次写完有缓存情况
[root@nfsserver kc10000]# time ll 2>&1 > /dev/null
real 0m0.228s
user 0m0.063s
sys 0m0.048s
内核客户端列目录20000文件，第一次写完有缓存情况
[root@nfsserver kc20000]# time ll 2>&1 > /dev/null
real 0m0.737s
user 0m0.141s
sys 0m0.092s
内核客户端列目录40000文件，第一次写完有缓存情况
[root@nfsserver kc40000]# time ll 2>&1 > /dev/null
real 0m1.658s
user 0m0.286s
sys 0m0.196s
都是比较快的返回，CPU可以忽略不计
现在重启mds后再次列目录
客户端如果不umount,直接重启mds的话,还是会缓存在
新版本这个地方好像已经改了（重启了mds 显示inode还在，但是随着时间的增长inode会减少，说明还是有周期，会释放，这个还不知道哪个地方控制，用什么参数控制，这个不是本篇着重关注的地方，后续再看下,jewel版本已经比hammer版本的元数据时间快了很多了）
[root@nfsserver kc10000]# time ll 2>&1 > /dev/null
real 0m0.380s
user 0m0.065s
sys 0m0.041s
[root@nfsserver kc10000]# cd ../kc20000/
[root@nfsserver kc20000]# time ll 2>&1 > /dev/null
real 0m0.868s
user 0m0.154s
sys 0m0.074s
[root@nfsserver kc20000]# cd ../kc40000/
[root@nfsserver kc40000]# time ll 2>&1 > /dev/null
real 0m1.947s
user 0m0.300s
sys 0m0.166s
测试都是看到很快的返回，以上都是正常的，下面开始将这个目录exportnfs出去，看下是个什么情况
负载问题复现
从nfs客户端第一次列10000个小文件的目录
[root@nfsclient kc10000]# time ll 2>&1 > /dev/null
real 0m4.038s
user 0m0.095s
sys 0m0.069s
从nfs客户端第一次列20000个小文件的目录
[root@nfsclient kc20000]# time ll 2>&1 > /dev/null
real 0m17.446s
user 0m0.175s
sys 0m0.141s
从nfs客户端第二次列20000个小文件目录
[root@nfsclient kc20000]# time ll 2>&1 > /dev/null
real 0m21.215s
user 0m0.182s
sys 0m0.151s
从nfs客户端第三次列20000个小文件目录
[root@nfsclient kc20000]# time ll 2>&1 > /dev/null
real 0m16.222s
user 0m0.189s
sys 0m0.143s
可以看到在20000量级的时候列目录维持在20000左右，CPU维持一个高位
从nfs客户端列40000个小文件的目录
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 7m15.663s
user 0m0.319s
sys 0m0.581s
[root@nfsclient kc40000]#
第一次列完，马上第二次列看下情况
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 1m12.816s
user 0m0.163s
sys 0m0.142s
可以看到第二次列的时间已经缩短了，再来第三次
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 1m33.549s
user 0m0.162s
sys 0m0.183s
可以看到在后面列的时候时间确实缩短了，但是还是维持一个非常高CPU的占用，以及比较长的一个时间，这个很容易造成过载
这个地方目前看应该是内核客户端与内核NFS的结合的问题
解决办法:用ganesha的ceph用户态接口替代kernel nfs
我们看下另外一种方案用户态的NFS+ceph同样的环境下测试结果：
从nfs客户端第一次列40000个小文件的目录
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 0m3.289s
user 0m0.335s
sys 0m0.386s
从nfs客户端第二次列40000个小文件的目录
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 0m1.686s
user 0m0.351s
sys 0m0.389s
从nfs客户端第三次列40000个小文件的目录
[root@nfsclient kc40000]# time ll 2>&1 > /dev/null
real 0m1.675s
user 0m0.320s
sys 0m0.391s
基本mds无多余的负载，非常快的返回
可以从上面的测试看到差别是非常的大的，这个地方应该是内核模块与内核之间的问题，而采用用户态的以后解决了列目录慢以及卡顿的问题
如何配置ganesha支持ceph的nfs接口
git clone -b V2.3-stable https://github.com/nfs-ganesha/nfs-ganesha.git
cd nfs-ganesha/
git submodule update --init --recursive
cd ..
cd nfs-ganesha/
ll src/FSAL/FSAL_CEPH/
cd ..
mkdir mybuild
cd mybuild/
cmake -DUSE_FSAL_CEPH=ON ../nfs-ganesha/src/
ll FSAL/FSAL_CEPH/
make
make -j 12
make install
vim /etc/ganesha/ganesha.conf
修改配置文件
EXPORT
{
Export_ID=1;
Path = "/";
Pseudo = "/";
Access_Type = RW;
NFS_Protocols = 4;
Transport_Protocols = TCP;
FSAL {
Name = CEPH;
}
}
停止掉原生的nfs
systemctl stop nfs
启用ganesha nfs
systemctl start nfs-ganesha.service
然后在客户端进行nfs的挂载即可
总结
ganesha在需要用到cephfs又正好是要用到nfs接口的时候，可以考虑这个方案，至少在缓存文件，降低负载上面能够比kernel client有更好的效果，这个可以根据测试情况用数据来做比较
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2017-12-04 |
/assets/images/blogimg/mds-use-too-more-cpu/
