Before reading some Linux network programming articles always encountered the file descriptor FD this thing, also did not quite understand. Read the following article about good, record it.
The original link
Wikipedia: The file descriptor is formally a non-negative integer. In fact, it is an index value that points to the record table of open files that the kernel maintains for each process. When a program opens an existing file or creates a new file, the kernel returns a file descriptor to the process. In programming, some low-level programming tends to revolve around file descriptors.
First, the concept of file descriptor
Linux system, take everything as a file, when a process to open an existing file or create a new file, the kernel returns a file descriptor to the process, the file descriptor is the kernel to efficient management has been created by open file index, used to refers to the file is opened, all I/O operation on the system call will pass file descriptors.
The relationship between file descriptors, files and processes
1. Description:
Each file descriptor corresponds to an open file
Different file descriptors may also point to the same file
The same file can be opened by different processes or multiple times in the same process
2. The system establishes three tables to maintain file descriptors
The file descriptor table at the process level
System-level file descriptor table
File system i-Node table (go to: Nguyen Yifeng — understand inode)
PS: To summarize hard and soft links. For hard links, the iNode number of the new file is the same as that of the original file. The number of links in the iNode of the original file is increased by one. If the original file is deleted, the new file is not affected. For soft connection, the iNode number of the new file is different from that of the original file. The number of links in the iNode of the original file remains the same. If the original file is deleted and the new file is accessed, no errors are reported.
3. Recognize file descriptors based on the three tables
In process A, file descriptors 1 and 30 both point to the same open file handle (#23), possibly because the process has performed the open operation multiple times
File descriptor 2 in process A and file descriptor 2 in process B both point to the same open file handle (#73). There are several possibilities, 1. Process A and process B may be parent-child processes. 2. Process A and process B open the same file with the same file descriptor (event with low probability =_=). 3.A process in A and B passes an open file descriptor to another process through A UNIX domain socket.
Descriptor 0 for process A and descriptor 3 for process B point to different open file handles, but they all point to the same entry in the I-Node table (#1936), in other words, to the same file. This happens because each process individually makes an open request to the same file. A similar situation occurs when the same process opens the same file twice.
Previous thinking, our ladder, this part of the reference from the web: links
Restrictions on file descriptors
Where there are resources, there are wars. File descriptors are a resource, and every process in the system needs file descriptors to carry out its world-changing ambitions. The world needs order, hence the rule of “file descriptor restrictions”.
The following table:
Soft refers to the Settings that are in effect on the current system
Hard refers to the maximum value that can be set in the system
- Soft and hard are both set
Command explanation:
ulimit
Copy the code
sysctl
Copy the code
Check the file descriptor of a process (nginx as an example, * pay attention to permissions, this example is in the local environment) :
Find the process ID that you want to check
As shown in the figure, the process ID found is 1367
View the limits of the process
As shown, in the Max Open Files line, you can see that the maximum number of file descriptors in the current setting is 1024
See how many file descriptors the process occupies
conclusion
In practice, if there are “Too many open files”, you can solve the problem by increasing the number of file descriptors available to the process, but often the story does not end like this. Most of the time, it is not because the process has Too few file descriptors available, but because of a bug. A large number of file connections were opened (Web connections can also occupy file descriptors) and not released. The fundamental way to solve “Too many Open Files” is to release the resources applied for by the program in time after they are used up.