为什么JDK NIO使用那么多的anon_inode文件描述符? [英] Why is the JDK NIO using so many anon_inode file descriptors?

问题描述

我正在使用Sun的JDK 1.6.0_26和NIO(带有Netty)，在lsof中，我看到了数百个anon_inode的文件描述符:

I'm using Sun's JDK 1.6.0_26 and NIO (with Netty) and in lsof I see hundreds of file descriptors that are anon_inode:

$ lsof -np 11225 | fgrep -w anon_inode
java    11225 nobody   57u     0000                0,9         0     1386 anon_inode
java    11225 nobody   61u     0000                0,9         0     1386 anon_inode
java    11225 nobody   65u     0000                0,9         0     1386 anon_inode
java    11225 nobody   69u     0000                0,9         0     1386 anon_inode
java    11225 nobody   73u     0000                0,9         0     1386 anon_inode
java    11225 nobody   77u     0000                0,9         0     1386 anon_inode
java    11225 nobody   81u     0000                0,9         0     1386 anon_inode
java    11225 nobody   86u     0000                0,9         0     1386 anon_inode
java    11225 nobody   89u     0000                0,9         0     1386 anon_inode
java    11225 nobody   93u     0000                0,9         0     1386 anon_inode
java    11225 nobody   97u     0000                0,9         0     1386 anon_inode
[...]

我找不到关于匿名inode是什么的明确解释，我在Linux内核的源代码树中查看了fs/anon_inodes.c，似乎是epoll使用了它，但是我不确定为什么我会有很多.我确实有多个"epoll循环"和计时器线程，但没有我的anon_inode数量那么多.

I couldn't find a clear explanation as to what an anonymous inode is, I looked at fs/anon_inodes.c in the Linux kernel's source tree and it seems that maybe epoll uses it, but I'm not sure why I would have so many. I do have multiple "epoll loops" and timer threads, but not nearly as many as my number of anon_inode.

推荐答案

这确实很可能是epoll.选择器默认从早期JDK 1.6.x版本之一开始使用epoll，并且此选择器impl除了套接字本身使用的描述符之外，还使用比旧版本更多的文件描述符.如果您在单个SocketChannel中注册多个选择器，例如，用于读取和写入的单独选择器，则还将使用更多文件描述符.如果Netty使用NIO，则几乎可以肯定会使用选择器.在一个应用程序中，由于使用了基于epoll的选择器，我的文件描述符与套接字的比率约为4:1.通过更改java.nio.channels.spi.SelectorProvider属性可以恢复到旧的选择器实现，这将减少描述符的数量，但可能会牺牲性能(YMMV).

It is indeed most probably epoll. Selectors use epoll by default starting with one of the early JDK 1.6.x releases and this selector impl uses more file descriptors than the old one in addition to the descriptors used by sockets themselves. You will also use more file descriptors if you register several Selectors with a single SocketChannel, for example separate selectors for reads and writes. If Netty uses NIO, it almost certainly makes use of selectors. In one app my file descriptors to sockets ratio was about 4 to 1 due to using epoll-based Selectors. It is possible to revert to the old selector implementation by changing the java.nio.channels.spi.SelectorProvider property and it will reduce the number of descriptors, but probably at the cost of performance (YMMV).

这篇关于为什么JDK NIO使用那么多的anon_inode文件描述符?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！