Solved High CPU Usage by "clock" Process After Upgrading to FreeBSD 14.2

satriani

satriani

Hello,

After upgrading one of my servers from FreeBSD 14.1 to 14.2, I've noticed that a process named clock consistently uses around 3% of the CPU. This behavior was not present before the upgrade.

The server is running with the following configuration:

FreeBSD Version: 14.2

Hardware:
  • AMD Ryzen™ 7 PRO 8700GE Octa-Core "Phoenix 1" (Zen4)
  • 64 GB DDR5 ECC RAM

Has anyone else experienced similar issues with the clock process after upgrading to 14.2? Any insights into why this might be happening or how to reduce its CPU usage would be greatly appreciated.

Thank you in advance for your help!

Best regards
 
1000071847.jpg
 
Hard to believe; if true, it would pretty much have to be a bizarre bug.

My suspicion is more that the tool you're using to display CPU usage is broken. Perhaps "broken" in the way that it looks just at the time that PID 2 is using CPU time, leading to a biased sample. Suggestion: Look at the long-term average, by comparing the elapsed time to the total CPU time used. You can for example do that with the ps command, with the options "-a" (to see all processes), and "-O etime,systime,usertime" to see how long this process ran for and how much CPU it has used over its life.
 
I have found the culprit: HAProxy running in a Jail. When I stop the HAProxy process, the CPU load caused by clock drops back to 0%
Now the question arises whether this behavior is normal, as HAProxy is essentially just balancing two databases.
 
Strange. Might be interesting to know how HAProxy manages to do that. If you want to debug it, you could try to use truss to see what system calls HAProxy is making.
 
I identified the source of the high CPU load caused by the clock kernel thread. The issue was related to HAProxy performing frequent health checks on specific backend servers using their IP addresses. These checks created significant overhead, likely due to the polling frequency and the use of network-based connections, which placed unnecessary load on the system.

The problem was resolved by disabling the health checks on the backend servers' IP addresses. HAProxy continues to function as expected, and the CPU load caused by the clock thread has dropped back to 0%. For my setup, Unix socket-based communication proved to be far more efficient, as it avoids the overhead of network-based health checks.
 
I landed here looking for a similar problem. The clock process is a kernel interval timer (usually a callout); There shouldn’t be anything different in 14.2; did you update the proxy package? Check your log for trace code; they may have left some debugging code on and a couple of printf can drive up the CPU substantially.
 
You must log in or register to reply here.
Back
Top