Linux 文件句柄的这些技术内幕,只有 1% 的人知道 |
您所在的位置:网站首页 › Linux句柄数 › Linux 文件句柄的这些技术内幕,只有 1% 的人知道 |
0
分享至
用微信扫码二维码 分享至好友和朋友圈 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 上海站 带您嗨聊一整天! 点击阅读原文,了解更多精彩 特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。 Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services. /阅读下一篇/ 返回网易首页 下载网易新闻客户端 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |