-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
virtual_memory() gives highly inaccurate results #685
Comments
Same results with psutil v3.1.1. |
From psutil doc:
In summary, in order to see the memory available you should rely on
I am not sure why this is different but both those values are tested against Line 159 in c4c70ef
...and here: Line 165 in c4c70ef
Could you run the test suite ( make test ) and see if they fail?
This is likely because we are comparing oranges and apples. psutil determines |
Sorry for the delayed response, but I have completed running tests. 3 tests fail: test_fetch_all, test_swapmem_free, and test_vmem_cached. The first one probably fails because of the network logins (it specifically reports it fails looking up UIDs and usernames). The other ones are more interesting and say the following:
So swapmem is off by ~2.6 GiB and vmem off by about ~144 MiB (on a machine with 24 GiB of RAM). On a different machine with a very similar setup but with 377.67 GiB of RAM I get just vmem_cached being off: (note: 59 tests were sipped, mostly due to lack of su priv) The tests were run with 4582e6b (most recent on master). |
…ier in python in order to avoid C typing issues
Sorry for getting to this so late. This looks like a C typing issue. Can you please try revision 50fd31a and re-run tests? |
OK, I consider this is fixed. |
Sorry for the massive delay in responding to this. I just checked out master again and ran make test and it still didn't work. The relevant failures are:
(on the machine with 377.67 GiB of RAM). I did have to remove the --user from the python setup.py develop --user in the Makefile to make it run (it said --user wasn't a valid option). There were additional failures as well (test_net_if_stats and test_net_io_counters both with a list index out of range, test_connections_unix with 5 != 7, test_cpu_times_comparison with 70147192.4 != 70147192.25999999 [just outside tolerance], and test_fetch_all like before). So I guess this problem isn't really fixed. Once again sorry for the delay in checking. |
Hi, I am also having a similar issue on Centos 7 with 1024MB ram and I'm testing with psutil release-4.1.0. However, my problem relates to calculating memory % used which seems to differ greatly from the output of the free command. A basic calculation on this machine with free shows 11% memory usage whereas with psutil it shows 22%. No matter what I try I can't seem to derive the 11% value from the psutil numbers.
The percentage calculation for memory used always seems to be very high compared to Example output from
The important thing to note here is the To work out % used with free I have been doing:
From the man page for free it says The raw output I get from psutil is:
Which in mb's is:
Here used is shown as 833mb which is quite high. So trying to derive the used number from psutil via the same method in free gives:
It's still a lot more than the 104mb given by I've cloned the latest master to the same machine. Will paste the output of BTW, thanks for psutil. It is an awesome library, I apologise in advance if I'm doing something silly with the numbers. My maths is not brilliant :) |
Output from
|
I'm guessing the
157mb vs 953mb being returned. Which is closer to the 104mb being returned when running free -m plus the memory overhead of running the tests etc. |
usedYou state that cachedThis is also weird. In summary, to me it appears that a certain version of "free" is wrong, not psutil. In this case perhaps it's best to "trust" the latest |
Note: in #800 I added "shared" memory. You may want to use that to play with numbers a little bit and see if you can match |
Just checked out the latest to give you accurate results. First, the The two memory-based failing tests outputs are (on a machine with ~377 GiB of RAM):
For the caches amount (which is off by about 190 GiB), |
So I read the manpage for my version of free, and it says cached is coming from the Cached and Slab lines of /proc/meminfo. Looking at meminfo, slab is ~180GiB which then gets the numbers pretty close. I don't know what slab memory really is, or if it should be counted, but that is an explanation. If it is not included in the |
And a discussion about |
And a description of the values Slab, SReclaimable, and SUnreclaim: https://access.redhat.com/solutions/406773 It seems that SReclaimable is that memory that could easily be used by other processes if necessary while SUnreclaim cannot be. SReclaimable + SUnreclaim = Slab. On this particular machine with ~377.7 GiB of RAM, SUnreclaim is 170.5 MiB while SReclaimable is 180.5 GiB. So in the end, I believe that if |
This Centos 7 machine is also on 3.3.10:
The first page of
Will give it at test on one of our ubuntu 12.04 boxes. It is very possible that the Centos 7 free package is doing something funky. |
On an Ubuntu 12.04 the test passes for test_used. And the numbers from free are:
Compared to the output of psutil:
The discrepancy does appear to be with Centos7 with the procps-ng package. I had a quick browse around the procps-ng gitlab repo and couldn't really work out if this was a brand new package that differed to the one on Ubuntu. |
Just noting that |
Fixed in #887 |
These commands were done right after each other:
free reports KiB and psutil gives bytes. After considering that, total is spot on and free is very close. The others are not though:
Overall it makes it look like I have only 4 GiB free when I should have ~46GB free.
Machine info:
The text was updated successfully, but these errors were encountered: