best way to discover this process's current memory usage, cross-platform?

[Alex Martelli]

Paul Boddie <paul at boddie.org.uk> wrote:

> Neal Norwitz wrote:
> > Valgrind actually runs on PPC (32 only?) and amd64, but I don't think
> > that's the way to go for this problem.
> 
> +1 for understatement of the week.
> 
> > Here's a really screwy thought that I think should be portable to all
> > Unixes which have dynamic linking.  LD_PRELOAD.
> 
> Similar work is described here:
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html

Interesting considerations.  Taking a step back, it does feel a bit as
if the amount of infrastructure needed for a process to ask about its
resource consumption is out of whack, though -- I don't understand why
Unix-like systems such as Linux and Darwin can't just fully support some
call such as getrusage.  Ah well...


> On the subject of memory statistics, I'm surprised no-one has mentioned
> "top" in this thread (as far as I'm aware): I would have thought such
> statistics would have been available to "top" and presented by that
> program.

It seems to me that top, like ps and other platform-dependent programs
such as vmmap on Darwin (MacOSX), tend to be at the very least owned by
group kmem and setgid, if not simply setuid root, because the way they
do their job is rooting through /dev/kmem and that requires privileges.
To let a Python extension module know how much VM the process is
currently using, we'd have to have the executable itself for Python be
setgid kmem or setuid root, which somehow doesn't seem appealing;-)

On MacOSX specifically, I've been pointed to an open-source third-party
utility named MemoryCell which does manage to learn about VM use for any
process w/o needing to be setuid or setgid.  It does so in a module
that's 300+ lines of ObjectiveC, so it would require quite a bit of
reverse engineering to integrate into a pure-C Python extension, but at
least it serves as proof of existence;-)


Alex