United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Release Found: Red Hat Enterprise Linux, all versions
You want to count how many file descriptors are currently in use on your Red Hat Enterprise Linux system.
Depending on what information you are looking for there are two ways to count file descriptors. The first method reports the number of file descriptors allocated by the kernel, the second method counts the number of open files on the system, including those, such as a mmap'd file, which do not consume file descriptors.
File descriptors are allocated in bunches by the kernel for performance reasons. When a new descriptor is needed and none are available, another bunch are requested. When too many are available, they are de-allocated in similar bunches. To see the number of allocated type:
# sysctl fs.file-nr
5760 0 102519
The three values in fs.file-nr denote the number of allocated file handles, the number of unused-but-allocated file handles, and the system-wide maximum number of file handles. The three column format is a hold-over from versions of the Linux kernel before 2.6 (eg, as used in Red Hat Enterprise Linux 3). In Red Hat Enterprise Linux 3 and earlier, subtracting the second number from the first gave you the number of actively used open file handles. In Red Hat Enterprise Linux 4 and later you would simply use the first number. The third number should be the same value as returned by the fs.file-max sysctl attribute.
To count the number of open file handles of any sort, run:
# lsof | wc -l
6480
This tells you that there are 6480 files by applications on the system. The same file opened by two applications will be counted twice.
The lsof utility reports 6480 open files, while fs.file-nr says 5760. So how many open files are there?
First, what is an open file?
Is an open file a file that is being used, or is it an open file descriptor? A file descriptor is a data structure used by a program to get a handle on a file, the most well know being 0, 1, 2 for standard in, standard out, and standard error. The fs.file-max kernel parameter refers to open file descriptors, and fs.file-nr gives us the current number of open file descriptors. But lsof lists all open files, including files which are not using file descriptors - such as current working directories, memory mapped library files, and executable text files. To illustrate, examine the difference between the output of lsof for a given pid and the file descriptors listed for that pid in /proc.
For this example, let's look at this process:
xli 5272 0.1 0.2 9784 2992 pts/2 S+ 11:31 0:00 vim .xchat2/xchat.conf
First, fun lsof and use grep to show only the files that relate to this process.
[root@rhel4 usr-4]# lsof | grep 5272
vim 5272 xli cwd DIR 3,7 4096 980162 /home/xli
vim 5272 xli rtd DIR 3,7 4096 2 /
vim 5272 xli txt REG 3,7 2727372 1786746 /usr/bin/vim
vim 5272 xli mem REG 3,7 93512 2191596 /lib/libselinux.so.1
vim 5272 xli mem REG 3,7 242880 2191595 /lib/libsepol.so.1
vim 5272 xli mem REG 3,7 101036 2191590 /lib/libnsl-2.5.so
vim 5272 xli mem REG 3,7 76392 2191591 /lib/libresolv-2.5.so
vim 5272 xli mem REG 3,7 15972 2189079 /lib/libattr.so.1.1.0
vim 5272 xli mem REG 3,7 46740 2189065 /lib/libnss_files-2.5.so
vim 5272 xli mem REG 3,7 21224 1774364 /usr/lib/libgpm.so.1.19.0
vim 5272 xli mem REG 3,7 1241272 1862354 /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
vim 5272 xli mem REG 3,7 15264 2191597 /lib/libutil-2.5.so
vim 5272 xli mem REG 3,7 13276 2191602 /lib/libtermcap.so.2.0.8
vim 5272 xli mem REG 3,7 121684 2189200 /lib/ld-2.5.so
vim 5272 xli mem REG 3,7 1576952 2191578 /lib/libc-2.5.so
vim 5272 xli mem REG 3,7 208344 2191585 /lib/libm-2.5.so
vim 5272 xli mem REG 3,7 16528 2191579 /lib/libdl-2.5.so
vim 5272 xli mem REG 3,7 125564 2191580 /lib/libpthread-2.5.so
vim 5272 xli mem REG 3,7 26028 2189111 /lib/libacl.so.1.1.0
vim 5272 xli mem REG 3,7 27836 2191599 /lib/libcrypt-2.5.so
vim 5272 xli mem REG 3,7 25460 1829892 /usr/lib/gconv/gconv-modules.cache
vim 5272 xli mem REG 3,7 124854 1929545 /usr/share/vim/vim70/lang/zh_CN/LC_MESSAGES/vim.mo
vim 5272 xli mem REG 3,7 135532 1929541 /usr/share/vim/vim70/lang/zh_CN.UTF-8/LC_MESSAGES/vim.mo
vim 5272 xli mem REG 3,7 55572000 1768511 /usr/lib/locale/locale-archive
vim 5272 xli 0u CHR 136,2 4 /dev/pts/2
vim 5272 xli 1u CHR 136,2 4 /dev/pts/2
vim 5272 xli 2u CHR 136,2 4 /dev/pts/2
vim 5272 xli 4u REG 3,7 12288 981204 /home/xli/.xchat2/.xchat.conf.swp
The following command will count these:
[root@rhel4 usr-4]# lsof -p 5272 | wc -l
29
Next, use ls to look into the /proc/pid/fd/ directory (where pid is the process of interest). This will show the open file descriptors.
[root@rhel4 fd]# ls -l /proc/5272/fd/
total 0
lrwx------ 1 xli xli 64 Jun 30 11:31 0 -> /dev/pts/2
lrwx------ 1 xli xli 64 Jun 30 11:31 1 -> /dev/pts/2
lrwx------ 1 xli xli 64 Jun 30 11:31 2 -> /dev/pts/2
lrwx------ 1 xli xli 64 Jun 30 11:31 4 -> /home/xli/.xchat2/.xchat.conf.swp
This process has only four open file descriptors, but there are almost thirty open files associated with it. Some of the open files which are not using file descriptors: library files, the program itself (executable text), and so on as listed above. These files are accounted for elsewhere in the kernel data structures (cat /proc/PID/maps to see the libraries, for instance), but they are not using file descriptors and therefore do not exhaust the kernel's file descriptor maximum.