Java进程无响应,但在我使用jstack -F进行线程转储后恢复。

huangapple go评论74阅读模式
英文:

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>



huangapple
  • 本文由 发表于 2020年8月6日 19:50:42
  • 转载请务必保留本文链接:https://go.coder-hub.com/63282982.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定