用户态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