Linux 文件句柄的这些技术内幕,只有 1% 的人知道-阿里云开发者社区

开发者社区> 高效运维> 正文
登录阅读全文

Linux 文件句柄的这些技术内幕,只有 1% 的人知道

简介: Linux内核暴露出来的指标对系统监控很有意义,认识这些指标背后隐含的对象以及增长原因,能够帮助我们在异常时找出问题所在。

image

1. 缘起

某个月朗风清的晚上,正在公司对面的深大操场跑步,突然接到同事发来的消息,他发现某机器上的文件句柄使用量有十一万多个(下面输出中的第一个字段)

image


但是通过运维常用的lsof命令算了下,相差甚远。

image


似乎很不科学,这里看到的数据不到1万个,剩下10多万的文件句柄哪里去了呢(系统完整性检查已排除黑客入侵可能性)

2. 文件描述符和文件句柄的故事

先看一张著名的图吧

image


这里我们先区分好两个概念:文件描述符和文件句柄

简单来说,每个进程都有一个打开的文件表(fdtable)。表中的每一项是struct file类型,包含了打开文件的一些属性比如偏移量,读写访问模式等,这是真正意义上的文件句柄。

文件描述符是一个整数。代表fdtable中的索引位置(下标),指向具体的struct file(文件句柄)。

3. file-nr 文件里的值是文件描述符还是文件句柄?

顺着内核代码找一下:

image

可以看出file-nr指标是由proc_nr_files函数处理,该函数最终其实是读取了nr_files全局变量

image

找下什么地方增加了这个值:

可以看到fs/file_table.c文件中第127行的get_empty_filp函数会增加这个值。那么这个函数是干什么的呢?

内核里面有注释“Find an unused file structure and return a pointer to it.”, 其实就是用来分配struct file的。

到此,相信你已经知道答案了。file-nr文件里面的第一个字段代表的是内核分配的struct file的个数,也就是文件句柄个数,而不是文件描述符。

4. 哪些地方会分配文件句柄?

知道文件句柄最终是通过get_empty_filp函数从filp cache中分配的之后,我们顺着函数调用链路简单梳理下,就能知道有哪些地方会分配文件句柄了:

open系统调用打开文件(path_openat内核函数)

打开一个目录(dentry_open函数)

共享内存attach (do_shmat函数)

socket套接字(sock_alloc_file函数)

管道(create_pipe_files函数)

epoll/inotify/signalfd等功能用到的匿名inode文件系统(anon_inode_getfile函数)

实际上,lsof的手册页也有部分描述:

image

5. 找出元凶

有了上面的知识,我们除了看lsof的输出之外,再通过ipcs命令看一下共享内存的情况:

image

居然有部分共享内存段被attach了9多万次,数量级对得上,毫无疑问就是它了!

可能有些同学会有疑问,同一个进程居然可以重复attach同一段共享内存那么次?答案是可以的,内核无限制。显然,这样做逻辑上是有问题的,对共享内存的正常操作,要么是attach后一直用,要么是attach用完之后就detach。

6. 排除了共享内存等的情况,我看到的file-nr值和lsof输出还是有很大差异?

上面的案例算是比较典型,然而,即便在一个比较“正常”的系统上,我们可以看到file-nr和lsof的输出还是有不小的差距的:

image

这里本质上是因为文件描述符和文件句柄是两个不同的东西:lsof在用户空间,主要还是从文件描述符的角度来看文件句柄。

我们来做一个实验:只打开一次文件,然后复制1000次文件描述符。测试代码如下:

image

image

我们启动dupfd进程打开了一次/dev/zero文件,复制了1000次文件描述符。file-nr中的文件句柄数只是个位数的变化,而lsof看到的结果涨了1000多。

如果我们把前面的代码换成open 1000次, 就可以看到file-nr和lsof的输出几乎都涨了1000。

lsof看到的是文件描述符不能代表文件句柄,还有一个有趣的例子。下面的mmap程序运行后。 文件句柄增加了将近1000, 而lsof看到的文件描述符才个位数:

image

我们来看一下测试的mmap程序代码:

image

代码中,我们循环1000次打开/dev/zero文件,之后mmap映射到进程地址空间,然后把这些打开的文件描述符都关掉。很显然,打开的描述符都被close掉了,不会有什么变化。 那为什么文件句柄数还是增加了1000个左右呢?

原来,linux内核中很多对象都是有引用计数的。 虽然文件句柄是由open先打开的,但mmap之后,引用计数被加1,尽管我们接着把文件描述符close掉了,但是底层指向的struct file由于引用数大于0,不会被回收。

通过上面两个例子,你应该知道lsof的输出和实际的文件句柄数有差距的原因了。

7. 如何找出内存映射间接占用的文件句柄?

实际上,不管是mmap映射文件,还是通过shmat连共享内存,最终都会在进程地址空间中分配一片内存区。 通过pmap命令可以看出一些端倪:

image

回到故事的开头。那个使用了11万文件句柄的机器,在内核slab cache中,除了文件句柄(struct file对象)对应的filp cache对象多之外,对应的内存区对象vm_area_struct占用也是超多的.
下面是slabtop的部分输出:

image

8. 还有其他lsof漏掉的情况吗?

当然有了,lsof是通过查看进程的内存映射和文件描述符表来枚举打开文件的, 如果是一个多线程的服务。主线程先退出了,子线程还活着, 那么进程的fd表看起来就是空的。

image

9. 总结
Linux内核暴露出来的指标对系统监控很有意义,认识这些指标背后隐含的对象以及增长原因,能够帮助我们在异常时找出问题所在。

原文发布时间为:2018-07-24
本文作者:高效运维
本文来自云栖社区合作伙伴“高效运维”,了解相关信息可以关注“高效运维

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

官网链接