在使用gluster3.3.0时，遇到各brickserver的glusterd进程频繁crash的问题。通过分析日志和源码，发现该问题可能由频繁调用volumestatusdetail方法导致，此方法引起过多文件句柄的创建，进而引发句柄泄露。测试验证了这一猜想，大量运行lsof命令发现文件句柄数持续增长。
在使用gluster 3.3.0的时候,发现各brick server的glusterd进程经常crash,日志中先出现
0-management: could not get inode size for ext4 : e2fsprogs package missing
0-management: failed to get inode size
然后进程就会被linux系统kill掉,log里报告说收到了11号signal
pending frames:
signal received: 11
在gluster源码中搜索"could not get inode size"
在xlators\mgmt\glusterd\src\glusterd-utils.c中可以看到该信息出现在
glusterd_add_inode_size_to_dict方法中,它报错说没有e2fsprogs包,但实际上该包已经被安装.
后来调查发现这个方法总是在调用 volume status XX detail时被调用,因此怀疑频繁调用 volume status detail方法会导致glusterd进程crash.
测试后果然发现volume status detail方法会打开过多的文件,造成fd leak.
多次运行
lsof -p 25595 | wc -l
gluster volume status MountCheck detail > /dev/null
lsof -p 25595 | wc -l
发现数量在持续增长.
0-management: could not get inode size for ext4 : e2fsprogs package missing
0-management: failed to get inode size
然后进程就会被linux系统kill掉,log里报告说收到了11号signal
pending frames:
signal received: 11
在gluster源码中搜索"could not get inode size"
在xlators\mgmt\glusterd\src\glusterd-utils.c中可以看到该信息出现在
glusterd_add_inode_size_to_dict方法中,它报错说没有e2fsprogs包,但实际上该包已经被安装.
后来调查发现这个方法总是在调用 volume status XX detail时被调用,因此怀疑频繁调用 volume status detail方法会导致glusterd进程crash.
测试后果然发现volume status detail方法会打开过多的文件,造成fd leak.
多次运行
lsof -p 25595 | wc -l
gluster volume status MountCheck detail > /dev/null
lsof -p 25595 | wc -l
发现数量在持续增长.
扫一扫
2908
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
