王子勇
腾讯高级业务运维工程师，有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 上海站 带您嗨聊一整天！
閱讀更多 高效運維 的文章
