when the Epoll handle is created, it will occupy an FD value, under Linux if look at the/proc/process id/fd/, is able to see this fd, so after using Epoll, you must call Close () closed, otherwise it may cause FD to be exhausted.
The FD created by Epoll is:
lrwx------1 root root 11:04 3-anon_inode:[eventpoll]
This type of inode is created by Epoll.
lrwx------1 root root 11:04 4-socket:[1126425]
An article:
It is well known that all open FD for this process is stored in the/proc/$pid/fd directory of the corresponding process. Of course, some may not have been opened by the process itself, as inherited from the parent process by fork (). This article focuses on the contents of the socket. When we use the Ls-l command to view in the FD directory, we see something like the following:
lrwx------1 root root * 09:44 133-/DEV/SDA1
lrwx------1 root root * 09:44 134-/DEV/SDB1
lrwx------1 root root * 09:44 136-/DEV/SDB1
lrwx------1 root root * 09:44 137-socket:[22460]
lrwx------1 root root * 09:44 138-socket:[7326842]
lrwx------1 root root * 09:44 139-socket:[7341066]
So this socket: what is the number behind the string? It is actually the inode number of the socket . As can be seen from the Linux kernel code net/socket.c, the following
/*
* Sockfs_dname () is called from D_path ().
*/
static char *sockfs_dname (struct dentry *dentry, char *buffer, int buflen)
{
Return Dynamic_dname (dentry, buffer, Buflen, "Socket:[%lu]",
Dentry->d_inode->i_ino);
}
So, what can we do when we know the inode number of the socket opened by a process? This involves/proc/net/tcp (UDP corresponds to/PROC/NET/UDP) file, which also lists the corresponding socket of the Inode number through this field, we can obtain additional information of this set of interfaces under/PROC/NET/TCP, such as the corresponding < Local Address: Port number, remote address: Port number > Pair, window size, status and other information. The specific field meanings are described in the Tcp4_seq_show function in net/ipv4/tcp_ipv4.c. Cat/proc/net/tcp as follows:
SL local_address rem_address St Tx_queue rx_queue tr tm->when retrnsmt uid Timeout inode
19:0100007f:83b8 0100007f:a57d 00000000:00000000 00:00000000 00000000 0 0 10879 1 f622edc0 20 4 31 3-1
20:0100007f:0fa0 0100007f:aa06 00000000:00000000 00:00000000 00000000 0 0 7326842 1 f5504dc0 20 4 11 5-1
Note: The code covered in this article is based on the Linux 2.6.30.1.
Another article:
Analysis of netstat statistics of TCP connections and the inconsistent number of socket type FD under ⁄PROC⁄PID⁄FD
Recently, an online application, found that the number of sockets slowly increased, and do not recycle, after the warning line, is automatically restarted by the operation and maintenance monitoring.
First, observing the JVM history on Zabbix, found that jvm-perm space had no data for the last two weeks, guessing that the program switched from JDK7 to JDK8. After asking the developer, the program has not been restarted for a long time and has only recently been republished. During this time, the Java operating environment on the line has been upgraded from JDK7 to JDK8.
Because there is no perm space in the JDK8, replaced by Metaspace.
Netstat
To the online server, use Netstat to count the number of connection in the process.
-l
found that compared to Zabbix on the number of statistics socket less than 100, netstat statistics only more than 100, and Zabbix on the monitoring data more than 300.
So to/proc/$pid/fd the number of FD for the socket type:
cd /proc/$pid/fdls -al | grep socket | wc -l
Discovery data is consistent with data on Zabbix.
Netstat is how to count the source code of the download netstat
Http://unix.stackexchange.com/questions/21503/source-code-of-netstat
source net-tools
From the Netstat code, it is possible to read the data inside the/PROC/NET/TCP to get the statistical information.
Java and C version of the simple Netstat implementation
Java version of
Http://www.cs.earlham.edu/~jeremiah/LinuxSocket.java
C Version of:
Http://www.netmite.com/android/mydroid/system/core/toolbox/netstat.c
Track Netstat with Starce
-antp
It can be found that Netstat has read a lot of the data under/proc. So it is generally possible to know that the netstat is the/proc/pid/fd below the data and/proc/net/the following data, in contrast to obtain statistical results.
Which sockets are not counted by netstat?
Again on the Internet to find the next, found here that the socket if created, no bind or connect, will not be netstat statistics.
Http://serverfault.com/questions/153983/sockets-found-by-lsof-but-not-by-netstat
In fact, that is, if the socket is created and not used, it will only be available under/PROC/PID/FD, without the relevant data in the/proc/net/.
After a simple test, it's true:
int socket = socket(PF_INET,SOCK_STREAM,0); //不使用
In addition, even if the socket is used, if the implementation of shutdown, just in the beginning, with Netstat can be counted to the state of the socket is fin_wait1. After a while, netstat statistics are not the information of the socket, but under the/proc/pid/fd, still can be found.
In the middle, I wrote a program, the/PROC/PID/FD under the Inode and/proc/net/below the data comparison, found that some sockets do not appear in the Inode/proc/net/.
View with Lsof
To view the socket inode with lsof:
Trigger GC, Recycle socket
Then try to trigger the GC to see if the socket will be recycled:
jmap -histo:live <pid>
As a result, the sockets are found to be recycled.
Then look at the Finalize method of Abstractplainsocketimpl:
/** * Cleans up if the user forgets to close it. */ protected void finalize() throws IOException { close(); }
You can see that the socket was close when it was in the GC.
Write a program to test under:
public class TestServer { public static void main(String[] args) throws IOException, InterruptedException { for(int i = 0; i < 10; ++i){ ServerSocket socket = new ServerSocket(i + 10000); System.err.println(socket); } System.in.read(); }}
First, to see the/PROC/PID/FD, you can find the relevant socket FD, and then trigger GC, you can find that the socket was recycled.
Other Dongdong Anon_inode:[eventpoll]
ls -al /proc/pid/fd
You can see that there are output like this:
-> anon_inode:[eventpoll]
This type of inode is created by Epoll.
Again, the selector implementation in Java under Linux is epoll with a pipe to implement the event notification function. So in the NIO program, there will be anon_inode:[eventpoll] and pipe type FD.
Why Tail-f/proc/$pid/FD/1 cannot read to stdout data
Http://unix.stackexchange.com/questions/152773/why-cant-i-tail-f-proc-pid-fd-1
Summarize
The reason is that after the JDK upgrade, the GC works differently and the FULLGC executes longer, resulting in some idle sockets not being recycled.
This article is chaotic, documenting some of the tools and techniques.
About the/proc/process idpid/fd