问题实践

IDEA调优

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


    -server
    -Xms1700m  # 最小堆
    -Xmx1700m  # 最大堆 配成一样是为了避免扩容
    -XX:MetaspaceSize=350m # 只是一个阈值, 达到该阈值才进行 GC
    -XX:MaxMetaspaceSize=350m # 最大值

    -Xnoclassgc 
    -Xverify:none # 不进行字节码校验
    -XX:+AggressiveOpts # 激进式优化

    -XX:ReservedCodeCacheSize=320m # IDEA JIT 缓存

参考: Java’s -XX:+AggressiveOpts: Can it slow you down?
参考: JVM参数MetaspaceSize的误解

FD泄漏： Unable to Open Socket File

jmap Error “Unable to Open Socket File”

不是同用户及用户组 uid和gid
目标JVM不健康
目标JVM使用了-XX:+DisableAttachMechanismJVM参数
执行工具的JVM和目标JVM不是同一个版本（最好保持一致，如果版本相差过大，内存布局设计不一样，就会无法正常解析结果）
/tmp 目录下无法创建命令使用的临时文件，或是来不及使用就被systemd-tmpfiles清理了 /tmp/.java_pidXXX

查找JVMSocket泄漏

一次由于网络套接字文件描述符泄露导致线上服务事故原因的排查经历
strace -t -T -f -p pid -e trace=network,close -o strace.out
- 尝试找到创建socket并没有关闭socket的线程号，然后进制转换后查看jstack找到线程持有栈关联到相关代码
处理过的案例： Apache DolphinScheduler V1.3.6 channel 未关闭导致socket泄漏
- 单纯从服务器现场看只能看到worker对master建立了大量socket，而且fd的特殊性无法判断socket真实建立时间
- 从worker和master的内存Dump入手，查看大量的socket（出问题时已4w+）会和哪些对象数量异常增多有关
- 排查可能异常的对象（优先看Netty和Socket有关的对象），对比上下文代码（优先关注对象创建和销毁处代码），最终定位到泄漏对象为NettyRemoteChannel，以及上述泄漏点
- 处理方式： remove前先关闭Channel

Practice

Contents

问题实践

IDEA调优

FD泄漏： Unable to Open Socket File

查找JVMSocket泄漏