【java】升级jetty-client解决Too many open files问题

宏辉

于 2024-08-08 02:00:59 发布

阅读量981

点赞数 18

分类专栏：解决各种报错问题文章标签： java jetty android

本文链接：https://blog.csdn.net/weixin_42914989/article/details/140955523

版权

解决各种报错问题专栏收录该内容

5 篇文章 0 订阅

订阅专栏

文章目录

升级jetty-client解决Too many open files问题

升级jetty-client解决Too many open files问题

问题背景

生产环境的采集经过一段时间就会报错 Too many open files，导致接下来的采集都会失败，已经严重影响到生产业务，于是抽空对此问题进行排查。
在这里插入图片描述

排查

看到日志报错的第一感觉是采集脚本每次都会去打开conf/application.properties文件，导致文件句柄占满没有被释放。于是先去排查定时调度的sdk源码，发现访问conf/application.properties文件的地方都会关流。

既然访问conf/application.properties文件的地方都会关流，就将注意力放在采集业务逻辑上，有可能是业务采集文件时候没有关流，导致文件句柄占满，进而导致访问conf/application.properties文件报错。

观察业务代码，采集中用到文件流的对象都放在try()中，代码执行完毕会自动关流，此处没有找到可疑点。但是业务中除了下载文件会打开文件流外，就只有保存文件时候会打开文件流。但是业务中保存文件是常用的sdk封装方法，其他系统业务也会用到，不可能会是这个地方有问题呀～

于是又再次去过一遍采集代码逻辑，排查是否有没关流的地方。排查未果。

让运维使用lsof -p PID命令观察正式环境采集程序打开文件句柄情况，得到大量以下日志。（具体可参考文章最后面的lsof拓展说明）

COMMAND     PID USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
java    2686219 root *455r      REG               0,49    207988 3442057181 /opt/file1.txt
java    2686219 root *456r      REG               0,49    149821 3442057183 /opt/file2.txt

从日志分析可以看到FD（文件描述符）中的值为r，说明采集文件处于被打开并处于只读模式。
而采集中唯一读文件的地方为保存文件的sdk方法。至此，排查方向改为研究sdk保存文件的方法。

原因

以下为文件保存方法的伪代码

import org.eclipse.jetty.client.util.MultiPartContentProvider;
import org.eclipse.jetty.client.util.PathContentProvider;
import org.eclipse.jetty.client.util.StringContentProvider;

@Override
	public CompletableFuture<Boolean> uploadAsync(String tableName, List<FileEntry> entryList) throws Exception {
		HttpRequest request = HttpUtils.newRequest("POST", url).timeout(timeoutInMills, TimeUnit.MILLISECONDS).header(HEADER_TOKEN_NAME, token);
		
		MultiPartContentProvider multiPart = new MultiPartContentProvider();
		for(FileEntry fileEntry : entryList) {
			
			String filePath = fileEntry.getLocalPath();
			File sourceFile = new File(filePath);
			String remotepath = fileEntry.getRemotePath();
			Map<String, Object> properties = fileEntry.getEntry().getProperties()==null? new HashMap<String, Object>() : fileEntry.getEntry().getProperties();
			properties.put(FILE_PATH, remotepath);
			
			multiPart.addFieldPart(ENTRY_NAME, new StringContentProvider(JsonUtils.obj2str(fileEntry.getEntry(), false)), null);
			multiPart.addFilePart(FILE_NAME, sourceFile.getName(), new PathContentProvider(Paths.get(filePath)), null);
		}
		
		multiPart.close();
		request.body(multiPart, null);
		.......
		}

其中multiPart.addFilePart()方法会打开文件，此处使用到了jetty-client进行文件读。
遇事不决问google，找到了一个类似没关句柄的issue：https://github.com/jetty/jetty.project/issues/3512
大致意思是jetty-client-v9.4.25之前的MultiPartIterator在遍历读文件时，content.iterator() 一直返回新的Iterator 对象。遍历后并没有将MultiPartIterator.iterator关闭，因此造成了文件句柄没有释放

在这里插入图片描述

解决

在这里插入图片描述
issue提及以及在jetty 9.4.25已经修复了该bug。升级jetty-client，查看源码，如下图：

可以发现升级后的jetty加上了关流代码。

测试环境升级jetty相关包，测试没有复现问题，至此问题解决。

lsof命令拓展

命令参数

-a 列出打开文件存在的进程
-c<进程名> 列出指定进程所打开的文件
-g 列出GID号进程详情
-d<文件号> 列出占用该文件号的进程
+d<目录> 列出目录下被打开的文件
+D<目录> 递归列出目录下被打开的文件
-n<目录> 列出使用NFS的文件
-i<条件> 列出符合条件的进程。（4、6、协议、:端口、 @ip ）
-p<进程号> 列出指定进程号所打开的文件
-u 列出UID号进程详情
-h 显示帮助信息
-v 显示版本信息

lsof输出各列信息的意义如下：

COMMAND：进程的名称
PID：进程标识符
PPID：父进程标识符（需要指定-R参数）
USER：进程所有者
PGID：进程所属组
FD：文件描述符，应用程序通过文件描述符识别该文件。如cwd、txt等:
（1）cwd：表示current work dirctory，即：应用程序的当前工作目录，这是该应用程序启动的目录，除非它本身对这个目录进行更改
（2）txt ：该类型的文件是程序代码，如应用程序二进制文件本身或共享库，如上列表中显示的 /sbin/init 程序
（3）lnn：library references (AIX);
（4）er：FD information error (see NAME column);
（5）jld：jail directory (FreeBSD);
（6）ltx：shared library text (code and data);
（7）mxx ：hex memory-mapped type number xx.
（8）m86：DOS Merge mapped file;
（9）mem：memory-mapped file;
（10）mmap：memory-mapped device;
（11）pd：parent directory;
（12）rtd：root directory;
（13）tr：kernel trace file (OpenBSD);
（14）v86 VP/ix mapped file;
（15）0：表示标准输入
（16）1：表示标准输出
（17）2：表示标准错误
一般在标准输出、标准错误、标准输入后还跟着文件状态模式：r、w、u等
（1）u：表示该文件被打开并处于读取/写入模式
（2）r：表示该文件被打开并处于只读模式
（3）w：表示该文件被打开并处于
（4）空格：表示该文件的状态模式为unknow，且没有锁定
（5）-：表示该文件的状态模式为unknow，且被锁定
同时在文件状态模式后面，还跟着相关的锁
（1）N：for a Solaris NFS lock of unknown type;
（2）r：for read lock on part of the file;
（3）R：for a read lock on the entire file;
（4）w：for a write lock on part of the file;（文件的部分写锁）
（5）W：for a write lock on the entire file;（整个文件的写锁）
（6）u：for a read and write lock of any length;
（7）U：for a lock of unknown type;
（8）x：for an SCO OpenServer Xenix lock on part of the file;
（9）X：for an SCO OpenServer Xenix lock on the entire file;
（10）space：if there is no lock.
TYPE：文件类型，如DIR、REG等，常见的文件类型:

（1）DIR：表示目录
（2）CHR：表示字符类型
（3）BLK：块设备类型
（4）UNIX： UNIX 域套接字
（5）FIFO：先进先出 (FIFO) 队列
（6）IPv4：网际协议 (IP) 套接字
DEVICE：指定磁盘的名称
SIZE：文件的大小
NODE：索引节点（文件在磁盘上的标识）
NAME：打开文件的确切名称