英文:
Java process not respoding but resuming after I do a thread dump with jstack -F
问题
我有一个关于Java进程的奇怪问题,它每天卡住一两次,只有在我执行以下命令后才能恢复:
jstack -F ${PID}
当Java进程卡住时,如果我尝试使用jcmd进行线程转储,我会收到AttachNotSupportedException异常。
我只能使用jstack -F来进行线程转储,并且必须使用与启动Java进程的JRE版本同步的JDK版本。
我唯一能想到的可能是操作系统的调度程序不允许Java进程使用CPU时间,而如果我执行jstack -F,它会强制允许Java进程运行?
对任何反馈都表示感谢。
问候,
Cristi
更新-1
今天又发生了。我首先检查了该服务器上的内存使用情况(99.1%)。然后,我执行了jmap -heap命令,然后在进行堆转储后进程恢复正常。附上了堆转储文件。
jmap -heap 7703
附加到进程ID 7703,请稍等...
调试器成功附加。
检测到服务器编译器。
JVM版本为25.162-b12
使用线程本地对象分配。
带2个线程的并行GC
堆配置:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 536870912(512.0MB)
NewSize = 89128960(85.0MB)
MaxNewSize = 178782208(170.5MB)
OldSize = 179306496(171.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104(20.796875MB)
CompressedClassSpaceSize = 1073741824(1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0(0.0MB)
堆使用情况:
PS Young Generation
Eden Space:
capacity = 143130624(136.5MB)
used = 73244792(69.85167694091797MB)
free = 69885832(66.64832305908203MB)
51.1733897003062% used
From Space:
capacity = 17825792(17.0MB)
used = 8176960(7.79815673828125MB)
free = 9648832(9.20184326171875MB)
45.871510225183826% used
To Space:
capacity = 17825792(17.0MB)
used = 0(0.0MB)
free = 17825792(17.0MB)
0.0% used
PS Old Generation
capacity = 243269632(232.0MB)
used = 23534032(22.443801879882812MB)
free = 219735600(209.5561981201172MB)
9.674052534432247% used
25964个已内部化字符串占用2759784字节。
更新-2
启用了GC日志后,当进程冻结时,以下是GC日志的尾部内容。
2020-09-02T06:51:11.286+0000: 86020.549: 应用程序线程停止的总时间:0.0001978秒,停止线程花费了:0.0000666秒
2020-09-02T06:51:11.286+0000: 86020.550: 应用程序时间:0.0000610秒
2020-09-02T06:51:11.286+0000: 86020.550: 应用程序线程停止的总时间:0.0001793秒,停止线程花费了:0.0000589秒
2020-09-02T06:51:11.287+0000: 86020.550: 应用程序时间:0.0003371秒
2020-09-02T06:51:11.287+0000: 86020.550: 应用程序线程停止的总时间:0.0001749秒,停止线程花费了:0.0000283秒
2020-09-02T06:51:11.287+0000: 86020.550: 应用程序时间:0.0001277秒
2020-09-02T06:51:11.287+0000: 86020.550: 应用程序线程停止的总时间:0.0001554秒,停止线程花费了:0.0000364秒
2020-09-02T06:51:11.287+0000: 86020.551: 应用程序时间:0.0000400秒
2020-09-02T06:51:11.287+0000: 86020.551: 应用程序线程停止的总时间:0.0001082秒,停止线程花费了:0.0000158秒
2020-09-02T06:51:11.288+0000: 86020.552: 应用程序时间:0.0010649秒
2020-09-02T06:51:11.288+0000: 86020.552: 应用程序线程停止的总时间:0.0001945秒,停止线程花费了:0.0000571秒
2020-09-02T06:51:11.289+0000: 86020.552: 应用程序时间:0.0001078秒
2020-09-02T06:51:11.289+0000: 86020.552: 应用程序线程停止的总时间:0.0001852秒,停止线程花费了:0.0000336秒
2020-09-02T06:51:11.289+0000: 86020.552: 应用程序时间:0.0000366秒
2020-09-02T06:51:11.289+0000: 86020.552: 应用程序线程停止的总
<details>
<summary>英文:</summary>
I have an weird issue with a Java process which is stuck (once/twice per day) and it only recovers after I execute:
jstack -F ${PID}
While the Java process is stuck, If I try to do a thread dump with jcmd, I receive AttachNotSupportedException.
I only managed to do a thread dump using jstack -F, and using JDK version in sync with JRE version, JRE version that was used to start the java process.
The only thing I can think of, is that maybe the OS Scheduler does not allow CPU time for the Java process, and if I do a jstack -F I force it to allow it to run?
Any feedback will be appreciated.
Regards,
Cristi
**UPDATE-1**
Today it happen again. First thing I have checked is the memory used (99.1%) on that box. Afterwards I have performed a jmap -heap, and process resumed without any issues after the heap dump. Heap dump attached.
jmap -heap 7703
Attaching to process ID 7703, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.162-b12
using thread-local object allocation.
Parallel GC with 2 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 536870912 (512.0MB)
NewSize = 89128960 (85.0MB)
MaxNewSize = 178782208 (170.5MB)
OldSize = 179306496 (171.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 143130624 (136.5MB)
used = 73244792 (69.85167694091797MB)
free = 69885832 (66.64832305908203MB)
51.1733897003062% used
From Space:
capacity = 17825792 (17.0MB)
used = 8176960 (7.79815673828125MB)
free = 9648832 (9.20184326171875MB)
45.871510225183826% used
To Space:
capacity = 17825792 (17.0MB)
used = 0 (0.0MB)
free = 17825792 (17.0MB)
0.0% used
PS Old Generation
capacity = 243269632 (232.0MB)
used = 23534032 (22.443801879882812MB)
free = 219735600 (209.5561981201172MB)
9.674052534432247% used
25964 interned Strings occupying 2759784 bytes.
**UPDATE-2**
After having GC logs enabled, when the process freezes, this is the tail of the GC log.
2020-09-02T06:51:11.286+0000: 86020.549: Total time for which application
threads were stopped: 0.0001978 seconds, Stopping threads took: 0.0000666 seconds
2020-09-02T06:51:11.286+0000: 86020.550: Application time: 0.0000610 seconds
2020-09-02T06:51:11.286+0000: 86020.550: Total time for which application threads were stopped: 0.0001793 seconds, Stopping threads took: 0.0000589 seconds
2020-09-02T06:51:11.287+0000: 86020.550: Application time: 0.0003371 seconds
2020-09-02T06:51:11.287+0000: 86020.550: Total time for which application threads were stopped: 0.0001749 seconds, Stopping threads took: 0.0000283 seconds
2020-09-02T06:51:11.287+0000: 86020.550: Application time: 0.0001277 seconds
2020-09-02T06:51:11.287+0000: 86020.550: Total time for which application threads were stopped: 0.0001554 seconds, Stopping threads took: 0.0000364 seconds
2020-09-02T06:51:11.287+0000: 86020.551: Application time: 0.0000400 seconds
2020-09-02T06:51:11.287+0000: 86020.551: Total time for which application threads were stopped: 0.0001082 seconds, Stopping threads took: 0.0000158 seconds
2020-09-02T06:51:11.288+0000: 86020.552: Application time: 0.0010649 seconds
2020-09-02T06:51:11.288+0000: 86020.552: Total time for which application threads were stopped: 0.0001945 seconds, Stopping threads took: 0.0000571 seconds
2020-09-02T06:51:11.289+0000: 86020.552: Application time: 0.0001078 seconds
2020-09-02T06:51:11.289+0000: 86020.552: Total time for which application threads were stopped: 0.0001852 seconds, Stopping threads took: 0.0000336 seconds
2020-09-02T06:51:11.289+0000: 86020.552: Application time: 0.0000366 seconds
2020-09-02T06:51:11.289+0000: 86020.552: Total time for which application threads were stopped: 0.0000910 seconds, Stopping threads took: 0.0000180 seconds
2020-09-02T06:51:11.289+0000: 86020.552: Application time: 0.0000412 seconds
2020-09-02T06:51:11.289+0000: 86020.553: Total time for which application threads were
</details>
# 答案1
**得分**: 1
如果在使用jcmd获取线程转储时收到AttachNotSupportedException错误,请尝试以与Java进程运行相同的用户身份运行jcmd。
请参阅https://stackoverflow.com/questions/25438983/com-sun-tools-attach-attachnotsupportedexception-unable-to-open-socket-file-ta。
<details>
<summary>英文:</summary>
If you receive AttachNotSupportedException while getting thread dump with jcmd try to run jcmd under the same user as java process runs.
See https://stackoverflow.com/questions/25438983/com-sun-tools-attach-attachnotsupportedexception-unable-to-open-socket-file-ta
</details>
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论