Closed GoogleCodeExporter closed 9 years ago
Original comment by billiej...@gmail.com
on 17 Mar 2009 at 4:19
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
Original comment by billiej...@gmail.com
on 17 Mar 2009 at 9:52
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
Percent utilization has been moved into issue 41.
Original comment by billiej...@gmail.com
on 20 Mar 2009 at 9:48
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
r289 attempts to implement a semi-reliable test case.
Original comment by billiej...@gmail.com
on 21 Mar 2009 at 12:39
[deleted comment]
[deleted comment]
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
Original issue reported on code.google.com by
jlo...@gmail.com
on 12 Mar 2009 at 4:37