其他分享
首页 > 其他分享> > 用户态fuse文件系统无响应导致系统宕机

用户态fuse文件系统无响应导致系统宕机

作者:互联网

用户态fuse文件系统无响应导致系统宕机

 

fuse是内核用户态文件系统

 

例如

fuse承载NFS(网络文件存储)是gluster服务,当gluster服务响应时间超过默认120s,导致内核hung死,触发echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message。

目前,NFS集群建设初期,内核fuse响应用户gluster服务的超时时间为900s,没有有效解决此类问题,gluster服务因网络、gan'e'sha服务、ctdb服务、samba服务多种原因,导致存储服务异常响应超时。

 

问题原因:

用户文件系统无规定120s内处理数据,导致内存溢出,系统无响应。

默认情况下, Linux会最多使用40%的可用内存作为文件系统缓存。当超过这个阈值后,文件系统会把将缓存中的内存全部写入磁盘, 导致后续的IO请求都是同步的。

将缓存写入磁盘时,有一个默认120秒的超时时间。 出现上面的问题的原因是IO子系统的处理速度不够快,不能在120秒将缓存中的数据全部写入磁盘。

IO系统响应缓慢,导致越来越多的请求堆积,最终系统内存全部被占用,导致系统失去响应。

 

常规解决办法:

根据应用程序情况,对vm.dirty_ratio,vm.dirty_background_ratio两个参数进行调优设置。 例如,推荐如下设置:

sysctl -w vm.dirty_ratio=10

sysctl -w vm.dirty_backgroup_ratio=5

sysctl -p

如果系统永久生效,修改/etc/sysctl.conf文件。加入如下两行:

#vi /etc/sysctl.conf

vm.dirty_backgroup_ratio = 5

vm.dirty_ratio = 10

重启系统生效。

 

尝试解决办法:

计划升级V4.0版本,涉及服务gluster、ganeha、samba;

目前由于客户业务跑在NFS存储集群上,正在研究通过热升级的方式,评估存储产品平滑升级的可能性。

计划升级V4.0解决的问题:

优先恢复客户业务,一般可以重启服务,临时解决存储使用问题;

  1. nfs文件存储内存占用过高

    sar -r -f /var/log/sa/sa15

  1. ganesha服务2049端口积压;

    ps -ef | grep -iE “2049|ganesha”

    kill -9 ....杀死少量established的2049的tcp连接,重启ganesha服务;

  1. nfs存储集群brick无法拉起,gluster v status中pid和online情况异常;

    查看brick状态

      gluster v status

      发现存储节点的pid为空,online为N离线状态;

    查看brick端口24007的有少量的established的tcp连接;

      ps -ef | grep 24007

      kill -9 .....杀死少量established的24007的tcp丽娜姐,重启gluster服务;

    对比所有节点,从glusterd.log日志中发现,brick的问题关联配置/var/lib/glusterd/vols/hnvol01cl01/info和/var/lib/glusterd/vols/sdsom_sql/info,此问题可能是/var/lib/glusterd/vols/sdsom_sql/info的配置同步异常,可以手动拷贝正常节点的配置文件进行同步。

参考:Linux文件系统一(用户文件系统fuse)_QQ851301776的博客-CSDN博客_fuse linux

标签:ratio,宕机,导致系统,文件系统,gluster,fuse,dirty,vm
来源: https://www.cnblogs.com/gkhost/p/16348097.html