查看linux文件描述符占用情况(linux下文件描述符和句柄)

我们在日常维护中,常遇到"too many open file"的错误,有的系统,比如ES,要求启动时候扩大打开文件描述符的个数,不如会有如下的提示:

[1]: max file descriptors [4096] for elasticsearch process likely too low, increase to at least [65536]

所以搞清楚文件描述符很重要,在限制文件描述符的时候,也常有这样的困惑,限制是对这个用户来讲的,还是对单个进程,还是对整个系统那,如果盲目扩大,可能引起一些资源耗尽性质的攻击。我对这些概念的了解也不是十分清楚,所以查阅了互联网上的资料和自己测试,才写了这篇文章,希望能对大家理解linux的文件描述符,有所帮助。

一 ulimit

ulimit 其实是限制shell,以及shell启动进程的使用资源情况,这样看起来ulimit限制是进程级别,我们可以通过ulimit命令方便地临时修改限制值。 比如我们修改打开文件数量:

ulimit -n 100

这样设置后,我们可以打开最多100个文件句柄数(这里面也是描述符数),测试如下:

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> int main(int argc,char * argv[]) { int i = 0; for (i = 0; i < 101; i ) { printf("open %d file.\n",i); // 打开文件会同时增加文件描述符和文件句柄数量 int f = open("/dev/zero",O_RDONLY); if (f > 0) { printf("open OK:%d \n",f); } else { printf("open error.\n"); } } }

用这样的程序跑一下,会发现在两个不同的终端,都最多可以打开97个文件描述符(说明限制是进程级别)

open 0 file. open OK:3 open 1 file. ... ... open OK:97 open 95 file. open OK:98 open 96 file. open OK:99 open 97 file. open error. open 98 file. open error. open 99 file. open error. open 100 file. open error.

为什么不是100个,是因为程序默认打开了标准输入,标准输出和标准出错三文件描述符,所以只剩下了97个文件描述符,而且是从3开始的,也验证了,打开文件从最小的未用的整数开始。 通过ulimit修改只是临时,生效,要永久生效,可以写到文件中:

vim /etc/security/limits.conf * soft noproc 20000 #软连接 * hard noproc 20000 #硬连接 * soft nofile 4096 * hard nofile 4096

  • 标识任意用户 soft 标识软限制,超过会告警;hard:硬限制,超过报错 nofile 打开文件描述符数量 nproc 打开进程数量。

重启后生效,如果不生效查看下登录模块是否引入限制如下:

[root@localhost ~]# cat /etc/pam.d/login|grep pam_limits.so session required pam_limits.so

limits.conf 文件实际是 Linux PAM(插入式认证模块,Pluggable Authentication Modules)中 pam_limits.so 的配置文件,而且只针对于单个会话。

如果不做限制,一个命令可导致必须重启机器:

:(){ :|:; }; :

你在设置ulimit -n 的时候,如果设置一个很大的值,会提示没有权限,即使你是root用户如下:

[root@localhost ~]# ulimit -n 3229825 -bash: ulimit: open files: cannot modify limit: Operation not permitted

原因是我们设置的值超过了单个进程能打开的最大文件数量:

cat /proc/sys/fs/nr_open [root@localhost ~]# cat /proc/sys/fs/nr_open 1048576 [root@localhost ~]# ulimit -n 1048576 [root@localhost ~]# ulimit -n 1048577 -bash: ulimit: open files: cannot modify limit: Operation not permitted

当我们设置小于等于单进程可以打开的最大文件数量后,就可以设置成功了,临时更改单个进程可以打开最大文件数量如下:

[root@localhost ~]# echo 3229826 > /proc/sys/fs/nr_open [root@localhost ~]# cat /proc/sys/fs/nr_open 3229826 [root@localhost ~]# ulimit -n 1048577

永久设置生效:

/etc/sysctl.conf 中添加或修 fs.nr_open值。

通过sysctl -p 生效,或者通过命令设置:

sysctl -w fs.nr_open=1000000

fs.nr_open限制单个进程打开最大文件数量

/proc/sys/fs/nr_open This file imposes a ceiling on the value to which the RLIMIT_NOFILE resource limit can be raised (see getrlimit(2)). This ceiling is enforced for both unprivileged and privileged process. The default value in this file is 1048576.

二 文件句柄和文件描述符

我们上面通过open函数返回的就是文件描述符,它是一个整数,每个进程都包含一个记录项,每个记录项内部都包含一个文件描述符表,里面包含文件描述符fd和一个文件指针,指向一个文件表,同一个文件打开多次会对应不同的文件表,不同的文件描述符,同上面的例子;多个文件描述符也可以指向不同的或相同的文件表, 这个文件表称为文件句柄,如下图:

查看linux文件描述符占用情况(linux下文件描述符和句柄)(1)

为什么要区分这两者那,因为我们通常用lsof查看的是文件描述符的数量,file-nr为文件句柄数量,通过命令查看:

cat /proc/sys/fs/file-nr

得到三个值,含义:

已分配文件句柄的数目 已分配未使用文件句柄的数目 文件句柄的最大数目

Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles -- this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.

file-nr文件里面的第一个字段代表的是内核分配的struct file的个数,也就是文件句柄个数,而不是文件描述符。通过上面的图关系我们可以看到,一个文件描述符肯定要有一个文件句柄,反过来,有一个文件句柄了,可能有多个文件描述符指向它,比如通过dup赋值文件描述符的情况或者父子进程情况,子进程会复制父进程的文件描述符表。

为什么要区分文件描述符和文件句柄,那是因为我们通过lsof查看的时候,查看到的是文件描述符,再测试下:

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> int main(int argc,char * argv[]) { int i = 0; int fd = open("/dev/zero",O_RDONLY); for (i = 0; i < 1000; i ){ // dup只是会增加文件描述符的数量, // 可能少量增加文件句柄数量或不增加看原来是否打开 int fdup = dup(fd); if (fdup >0 ) { printf("dup file:%d ,des:%d ok\n",i,fdup); } else { printf("dup file:%d error.\n",i); } } pause(); }

我们写了这样一段代码,编译在另外一个终端运行,运行前面,通过下面的命令查看打开的句柄数量,和文件描述符的数量;运行后发现,lsof查看的文件描述符的数量增加了一千多,而文件句柄的数量没有增加,说明了,lsof查看的是文件描述符,通过测试我们也发现了ulimit -n限制的就是文件描述符的数量。

查看linux文件描述符占用情况(linux下文件描述符和句柄)(2)

是不是文件描述符的数量一定比文件句柄多那,找了个例子测试下:

#include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> void testm() { char * addr = NULL; int fd = open("/dev/zero",O_RDONLY); if (fd == -1 ){ printf("open error.\n"); } addr = mmap(NULL,4096,PROT_READ,MAP_PRIVATE,fd,0); if (addr == MAP_FAILED) printf("Map error"); else { // munmap(addr,4096); } close(fd); } int main(int argc,char * argv[]) { int i = 0; for (; i<1000; i ) testm(); pause(); }

运行发现,文件描述符的数量变化很小,而文件句柄的数量增加一千个左右,原因是文件描述符我们通过close(fd)关闭了,而通过mmap映射的内存块没有关闭,而文件句柄包含了映射的内存,没有释放,通过:

[testm@localhost ~]$ pmap -p 7226|grep "dev/zero" |wc -l 1000

核对进程打开的映射内存是对的。

查看linux文件描述符占用情况(linux下文件描述符和句柄)(3)

如果把注释的代码放开:munmap(addr,4096); ,这样的话文件句柄就不会怎么增加的。

三 file-max

file-max即整个linux系统能打开的文件总数,默认值是系统总内存(以KB为单位)/10, 查看办法:

cat /proc/sys/fs/file-max 766846

更改file-max的大,临时生效

echo 786046 > /proc/sys/fs/file-max 或 sysctl -w fs.file-max=786046

永久生效:

echo fs.file-max=786046 >> /etc/sysctl.conf sysctl -p

说明:

man 5 proc: /proc/sys/fs/file-max This file defines a system-wide limit on the number of open files for all processes. System calls that fail when encountering this limit fail with the error ENFILE.

四 总结

文件句柄和文件描述符是两个不同东西,文件句柄对应:

1. open系统调用打开文件(path_openat内核函数) 2. 打开一个目录(dentry_open函数) 3. 共享内存attach (do_shmat函数) 4. socket套接字(sock_alloc_file函数) 5. 管道(create_pipe_files函数) 6. epoll/inotify/signalfd等功能用到的匿名inode文件系统(anon_inode_getfile函数)

通过:

cat /proc/sys/fs/file-nr

查看占用的句柄数量

文件描述符对应的有:

1. 文件为REG 2. 目录 DIR。 3. CHR表示字符设备 4. BLK标识块设备。 5. unix, FIFO, Ipv6分表表示UNIX域套接字,FIFO队列和IP套接字。

通过:

lsof -n|awk ‘{print $2}’|sort|uniq -c|sort -nr|more | grep [PID]

命令看看进程打开的文件描述符。

六 参考

[https://blog.csdn.net/u013256816/article/details/60778709](https://blog.csdn.net/u013256816/article/details/60778709) [https://www.sohu.com/a/242941944_262549](https://www.sohu.com/a/242941944_262549)

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页