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

大家好，欢迎来到IT知识分享网。

王子勇

腾讯高级业务运维工程师，有10年研发与运维工作经验。崇尚开源，喜欢钻研系统技术。微信号: jacuro

1. 缘起

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

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

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

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

先看一张著名的图吧

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

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

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

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

顺着内核代码找一下：

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

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

可以看到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的手册页也有部分描述：

5. 找出元凶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. 总结

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

9 月的上海，运维人有个必去的地方，第10 届 GOPS ，回到起点，回到初心！

AIOps 风向标！ GOPS 全球运维大会 2018 · 上海站震撼来袭！

GOPS 2018 上海站 亮点之一：腾讯运维双雄：聂鑫、大梁带现身 GOPS 上海站 带您嗨聊一整天！

点击阅读原文，了解更多精彩