HiveServer2 文件描述符泄漏

 

现象

用户反馈 hs2 打开的文件描述符的数量一直在涨,但是当前 hs2 的连接只有个位数。

wecom-temp-86668-466aa580e0ca33aef0dd18c39de36447.png

 

排查过程

首先找到 hs2 进程持有了哪些文件描述符,通过 lsof 命令 lsof -p $pid ,看到 hs2 进程确实在 /data/emr/hive/tmp/operation_logs/ 目录下打开了大量描述符

在 jira 中找到一个类似 的 issue: [HIVE-10970] Investigate HIVE-10453: HS2 leaking open file descriptors when using UDFs - ASF JIRA (apache.org)

但是这个场景是由于 UDF 导致的 fd 泄漏,并且泄漏路径是在 hive.downloaded.resources.dir 路径下,跟 operation_logs 目录不一样.看上去不是同一个问题

排查源码 , 找到 operation log 有一个清理逻辑
org.apache.hive.service.cli.operation.Operation#cleanupOperationLog

猜测是在客户端 session 异常结束 的时候,这个方法没有被正常调用到或者清理逻辑有漏洞导致的

首先过一遍 session 关闭的逻辑,通过分析 beeline 客户端的火焰图,找到 session 关闭起始点
org.apache.hive.jdbc.HiveStatement#closeClientOperation
Pasted image 20230303195911.png

这里 client 发起了一个 thrift rpc 调用,然后在 hs2 thrift 找到 thrift server 对应的方法 org.apache.hive.service.cli.thrift.ThriftCLIService#CloseOperation
跟踪这个方法,最终会走到 org.apache.hive.service.cli.operation.SQLOperation#close
这里会调用 cleanupOperationLog 方法
Pasted image 20230303200607.png

那么确实是有可能由于客户端 session 异常退出,operation logs 没有被清理的可能的

接着查看 cleanupOperationLog 逻辑, 看这里是否有代码 bug ,于是在 idea 中使用 git 分支比较功能,发现 3.1 版本提交了一个修复

Pasted image 20230303193129.png

[HIVE-18820] Operation doesn't always clean up log4j for operation log - ASF JIRA (apache.org)

 

结论

  • 客户端 session 异常退出,导致 operation logs 没有被清理,跟 scratch dir 没有被清理场景类似
  • HIVE-18820 社区 bug 导致,可以考虑合入这个 patch
原创作者: hdpdriver 转载于: https://www.cnblogs.com/hdpdriver/p/18422577
定位 Android 系统中文件描述符泄漏的问题,尤其是在涉及 `/system/lib64/libfdtrack.so` 的情况下,可以通过以下方法进行系统性排查和分析。 ### 启用文件描述符跟踪功能 Android 提供了文件描述符跟踪机制,可以通过启用 `libfdtrack.so` 来记录每个文件描述符的打开和关闭情况。该机制通常用于调试阶段,通过在系统中设置特定的环境变量或启动参数来激活。例如,可以在系统启动时添加 `debug.fdtrack=true` 参数,或在运行时通过 `setprop` 命令设置属性来启用跟踪功能。启用后,系统会记录每个文件描述符的生命周期,帮助识别未正确关闭的资源。 ### 使用调试工具分析跟踪信息 在启用文件描述符跟踪后,可以使用 `gdb` 或 `strace` 等调试工具来查看 `libfdtrack.so` 记录的跟踪信息。这些工具可以显示文件描述符的分配路径、调用栈以及未关闭的句柄,从而帮助定位泄漏的根源。例如,通过 `strace -f -o output.log your_app` 命令可以捕获应用运行过程中所有系统调用的信息,包括文件描述符的打开和关闭操作。 ### 检查系统日志与堆栈信息 Android 系统日志(Logcat)中可能会记录与文件描述符相关的异常信息。通过查看日志中的 `W`(警告)或 `E`(错误)级别条目,可以发现潜在的资源泄漏线索。例如,如果某个应用尝试打开过多文件描述符并触发 `Too many open files` 错误,则表明可能存在泄漏问题。此外,使用 `dumpsys meminfo` 命令可以查看内存使用情况,结合 `--unreachable` 参数可尝试识别未被释放的资源。 ### 分析 HPROF 文件以识别对象引用链 在某些情况下,文件描述符泄漏可能与 Java 层的对象引用有关。此时可以使用 Android Profiler 或 `Android Studio` 打开 HPROF 文件,分析对象之间的引用链路,确认是否存在未被释放的资源持有。裁剪后的 HPROF 文件仍然保留了完整的对象结构和引用链路,因此即使不显示基础数据类型的值,也不会影响对内存泄漏的分析[^1]。 ### 检查 32/64 位兼容性问题 由于 `libfdtrack.so` 存在于 `/system/lib64/`(64位)和 `/system/lib/`(32位)目录中,确保应用加载的库版本与自身架构一致。如果 32 位应用尝试加载 64 位的 `libfdtrack.so`,会导致兼容性错误,反之亦然。可以通过 `readelf -h` 命令检查库文件的架构,确保其与应用的 ABI 匹配。 ### 示例代码:监控文件描述符使用情况 ```c #include <fcntl.h> #include <unistd.h> #include <stdio.h> int main() { int fd = open("/tmp/testfile", O_CREAT | O_RDWR, 0666); if (fd == -1) { perror("open"); return 1; } printf("Opened file with FD: %d\n", fd); close(fd); printf("Closed FD: %d\n", fd); return 0; } ``` 上述代码演示了如何打开和关闭一个文件,并打印其文件描述符。通过结合调试工具和日志输出,可以更直观地监控文件描述符的使用情况。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值