search

end18 / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

Support for per-process memory bytes/KB utilization #38

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
psutil should support per-process memory utilization statistics in both raw
(e.g. bytes) numbers and % utilization.

Original issue reported on code.google.com by jlo...@gmail.com on 12 Mar 2009 at 4:37

GoogleCodeExporter commented 9 years ago

Original comment by billiej...@gmail.com on 17 Mar 2009 at 4:19

GoogleCodeExporter commented 9 years ago 
As for raw bytes information we need to decide what values we want to return.
Since figuring out how memory works on all different platforms is very complex 
as for
now I think we better return the minimal information possible for simplicity 
and add
more detailed information in future releases.

Figuring out which information are portable between different platforms is also 
of
primary importance.

On Linux we can easily retrieve virtual and resident memory, known under ps by 
the
name of VMS and RSS respectively, but I'm not sure that summing them will give 
us the
total memory used by the process (for example, this article makes me raise more 
than
one doubt:
http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.h
tml).

As for the data type we want our get_memory_info() function to return I think 
we have
two options:

- returning a tuple, like we did for get_cpu_usage() function
- returning a MemoryInfo class instance similar to ProcessInfo containing memory
values accessible as class attributes

Considering that in future release we might add new memory information, using a
MemoryInfo class would make more sense to avoid breaking backward compatibility.

My2cents

Original comment by billiej...@gmail.com on 17 Mar 2009 at 9:50

GoogleCodeExporter commented 9 years ago

Original comment by billiej...@gmail.com on 17 Mar 2009 at 9:52

GoogleCodeExporter commented 9 years ago 
We should provide properties for RSS and VMS just like top/ps/taskmgr all do. 
The
numbers should not be added since in most cases it is desirable to differentiate
between virtual memory size and resident memory size. From what I've seen all
platforms differentiate between the two and it's reasonably straightforward to
retrieve RSS/VMS per-process.

I'm not decided on what the implementation should be but I think it makes sense 
to
have the interface be simple properties for rss/vms and perhaps mem_util or 
something
like that for % utilization.

Original comment by jlo...@gmail.com on 20 Mar 2009 at 6:40

GoogleCodeExporter commented 9 years ago 
Percent utilization has been moved into issue 41.

Original comment by billiej...@gmail.com on 20 Mar 2009 at 9:48

GoogleCodeExporter commented 9 years ago 
Implemented on OS X, FreeBSD, Windows and Linux as r277, r278, r279 and r280.
Leaving this open as long as test cases are available and working.

Original comment by billiej...@gmail.com on 21 Mar 2009 at 2:04

GoogleCodeExporter commented 9 years ago 
r289 attempts to implement a semi-reliable test case.

Original comment by billiej...@gmail.com on 21 Mar 2009 at 12:39

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Updated csets after the SVN -> Mercurial migration:
r277 == revision 4ff2f6621026
r289 == revision decb1e50ad3f

Original comment by g.rodola on 2 Mar 2013 at 11:47