[
https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850467#comment-17850467
]
Mark Linley edited comment on DAEMON-460 at 5/31/24 1:01 PM:
-------------------------------------------------------------
Hi
Our Java application is managed as a Windows service by Apache Commons Daemon.
Upgrading to v1.3.4 showed what others have been seeing. One of the CPU cores
constantly sits at close to 100% CPU utilization.
I was able to successfully configure Visual Studio 2022 to do remote debugging
of prunsrv.exe v1.3.4.
I analyzed the CPU profile in Visual Studio once the debugger was connected to
the remote prunsrv.exe process. I could see one of the threads of prunsrv.exe
consuming almost 100% of the CPU. I looked at the top function, based on CPU
usage, and it was prunsrv.c::apxJavaWait. With a breakpoint activated, my
attention was drawn to this code in prunsrv.c::serviceMain :
!image-2024-05-29-15-56-35-585.png!
I could see in my debug session that the wait of 2 seconds is definitely not
happening, resulting in the loop iterating as fast as the CPU core will allow
it to, which likely explains the 100% CPU core utilization issue. Pull request
64, mentioned above, did add this loop so it could be related to the problem we
are seeing.
Stepping into apxHandleWait you arrive at the method prunsrv.c::apxJavaWait
that receives the timeout value of 2000 milliseconds but the timeout value is
effectively never used because the code keeps returning here:
!image-2024-05-29-15-57-37-665.png!
Here is the CPU usage breakdown by C function from the Visual Studio 2022
diagnostic tool, the VM has 4 cores allocated, so you can see that one core is
maxed out:
!image-2024-05-31-10-00-10-916.png!
If someone more experienced in C or one of the maintainers could comment, I'd
appreciate it. I'm a Java developer :)
Thanks!
Mark
was (Author: plasm0r):
Hi
Our Java application is managed as a Windows service by Apache Commons Daemon.
Upgrading to v1.3.4 showed what others have been seeing. One of the CPU cores
constantly sits at close to 100% CPU utilization.
I was able to successfully configure Visual Studio 2022 to do remote debugging
of prunsrv.exe v1.3.4.
I analyzed the CPU profile in Visual Studio once the debugger was connected to
the remote prunsrv.exe process. I could see one of the threads of prunsrv.exe
consuming almost 100% of the CPU. I looked at the top function, based on CPU
usage, and it was prunsrv.c::apxJavaWait. With a breakpoint activated, my
attention was drawn to this code in prunsrv.c::serviceMain :
!image-2024-05-29-15-56-35-585.png!
I could see in my debug session that the wait of 2 seconds is definitely not
happening, resulting in the loop iterating as fast as the CPU core will allow
it to, which likely explains the 100% CPU core utilization issue. Pull request
64, mentioned above, did add this loop so it could be related to the problem we
are seeing.
Stepping into apxHandleWait you arrive at the method prunsrv.c::apxJavaWait
that receives the timeout value of 2000 milliseconds but the timeout value is
effectively never used because the code keeps returning here:
!image-2024-05-29-15-57-37-665.png!
If someone more experienced in C or one of the maintainers could comment, I'd
appreciate it. I'm a Java developer :)
Thanks!
Mark
> High CPU usage in prunsrv.exe since Daemon 1.3.3
> ------------------------------------------------
>
> Key: DAEMON-460
> URL: https://issues.apache.org/jira/browse/DAEMON-460
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
> Affects Versions: 1.3.3
> Reporter: Japie vd Linde
> Priority: Major
> Attachments: EspRun-Service-Log.2023-06-05.log,
> image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png,
> image-2024-05-29-15-56-35-585.png, image-2024-05-29-15-57-37-665.png,
> image-2024-05-31-10-00-10-916.png
>
>
> When using the --StopTimeout=30 parameter on service using prunsrv the CPU
> usage is reported as very high on Windows. Rolling back to older prunsrv
> seems to resolve the problem.
> !image-2023-05-31-09-31-21-485.png!
> What could be the possible causes for this problem?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
