Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[macOS] psutil.Process(pid).cpu_percent calculation result is inaccurate #2411

Open
RLYRLY opened this issue Apr 22, 2024 · 8 comments
Open

Comments

@RLYRLY
Copy link

RLYRLY commented Apr 22, 2024

Summary

  • OS:macOS 13.6.5 (22G621)
  • Architecture: ARM64
  • Psutil version: 5.9.8
  • Python version: 5.7.7
  • Type: core, CPU

Description

By using psutil.Process(pid).cpu_percent(interval=1) to get the cpu utilization of a process, and then using the cpu utilization obtained by the top command or the htop command to verify the results of psutil, it is found that the results calculated by psutil are completely inconsistent.

example:
image
htop command: 4.1%

proc = psutil.Process(pid)
cpu_usage = proc.cpu_percent(interval=1)
print(f"Process '{proc.name()}' (PID: {proc.pid}) CPU utilization: {cpu_usage}%")
image
psutil:0.1%

@RLYRLY RLYRLY added the bug label Apr 22, 2024
@github-actions github-actions bot added the macos label Apr 22, 2024
@RLYRLY RLYRLY changed the title [OS] title [macOS] psutil.Process(pid).cpu_percent calculation result is inaccurate Apr 22, 2024
@giampaolo
Copy link
Owner

How are you comparing the 2? If you want to compare with top/htop you should do it in a loop, like this:

p = psutil.Process(PID)
while 1:
    print(p.cpu_percent(interval=None)
    time.sleep(1)

@RLYRLY
Copy link
Author

RLYRLY commented Apr 23, 2024

@giampaolo First of all, thank you for your help. I used loops for benchmarking and there is no change. Under arm64, the cpu utilization of the psutil calculation process is very different from that of htop calculation. In addition, I use other mac (inter chips), and the calculation results are basically the same as htop.

@RLYRLY
Copy link
Author

RLYRLY commented Apr 26, 2024

@giampaolo Hello, please help me answer this question if you have time, it is very important to me.

@giampaolo
Copy link
Owner

Sorry but I have no idea. I don't have the hardware to test this against. Perhaps on arm64 process CPU metrics work differently and require using a different API. It would not be a first on macOS.

@RLYRLY
Copy link
Author

RLYRLY commented Apr 26, 2024

@giampaolo Understood, thank you, if there is any progress in the future, please try to synchronize it. Let me investigate the specific reasons here.

@zhang25121
Copy link

I ran into the same problem on a 32 core window machine, and I found that on powerful machines, the CPU cores didn't always work

@dbwiddis
Copy link
Contributor

dbwiddis commented Aug 8, 2024

I suspect the issue is a conversion based on the clock frequency somewhere.

x64 uses 1 tick per millisecond.
aarch64 uses 3 ticks per 125 milliseconds. You can find the conversion in the timebase_frequency field of any CPU in the IORegistry.

Here's a Java/JNA-based calculation of the offset: https://github.com/oshi/oshi/blob/099a4a1153effdfe4547c25052d2df4961e4d7eb/oshi-core/src/main/java/oshi/software/os/mac/MacOSProcess.java#L62-L88

If you multiply the psutil value by 41.6666... (125/3) do you get the expected result?

See also my answer at https://stackoverflow.com/a/76151406/1161484 with more detail including (untested) C code that might be appropriate here.

@dbwiddis
Copy link
Contributor

dbwiddis commented Aug 8, 2024

As a follow-up, I see the existing code uses the CLK_TCK constant for division, which apparently doesn't work on arm64. The linked SO post in my previous comment also includes a few other native command calls available on arm64 mac which might be able to be used at compile time rather than my Java run-time hack.

In any case, I'm pretty sure the answer is as simple as "on Apple Silicon, multiply by 125/3" and finding the right way to define that in the code is something I'll leave to the C experts.

See also same bug/fix on my Java-based repo:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants