一、问题描述
2021-01-06 10:50:00 运维同学反馈生产环境文件服务节点物理内存使用率过高超过运维设置的安全范围,现象观察2020-12-17--2021-01-06长时间内存无法释放。
二、问题零时解决方案
- 快速定位问题
根据经验快速查找影响内存使用的指标 老年代、新生代、元空间、非堆内存使用、网卡上下行流量、CUP使用率发现这几类指标正常,程序也没有使用堆外空间,是谁使用掉这么多内存?带着疑问发现图6中线程数上升趋势异常,其中线程状态为TIMED_WAITING的线程数上升最多。
节点监控指标图汇总 | |
---|---|
|
|
|
|
|
|
- 问题零时解决
从监控上看来,这个问题有是线程无法释放导致。其持有的内存资源也无法释放,导致节点物理内存长期(2020-12-17--2021-01-06)偏高。零时解决办法重启节点,重启节点后观察一天,节点的内存使用没有在上升。
三、内存泄漏原因分析
-
DUMP分析
dump无任何异常,dump分析比较简单不做多介绍。
-
一个线程占用多少内存
Linux一条线程占用多少内存?
#linux默认一个线程占用8M内存
[logview@vm-xy-vmc-file-p02 ~]$ ulimit -s
8192
Java一条线程占用多少内存?
java线程占用内存也就是java的栈空间大小,可通过-Xss参数设定,除非出现栈溢出一般不做设置
[logview@vm-xy-vmc-file-p02 ~]$ java -XX:+PrintFlagsFinal -version | grep ThreadStackSize
intx CompilerThreadStackSize = 0 {pd product}
#应用线程大小
intx ThreadStackSize = 1024 {pd product}
#JVM内部线程大小比如GC线程
intx VMThreadStackSize = 1024 {pd product}
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Java线程 VS Linux线程?
相同点:线程是操作系统的最小调度单位,都需要获取CUP时间片的,CUP时间片是先分配给进程,进程在分配给线程。
不同点:Java线程是属于JVM进程的线程,Linux线程分为内核线程、用户线程具体与CUP交互的方式都不同,具体不同在哪里目前也不知道。本帖是关于Linux线程与Java变成的讨论。
-
Java线程状态解读
NEW 创建、 RUNNABLE 就绪、BLOCKED 阻塞、WAITING 不定时等待、TIMED_WAITING 定时等待、TERMINATED 线程终止。 关于更多Thread解读。
四、问题解决过程
待更新(由于我们线程日志被覆盖了,目前无任何线索了,后续遇到类似问题,在继续分析)