how to get statistics about memory usage ?

[Christophe Lohr]

Hi,

Inside a program, I need to get some statistics about memory usage.
I actually need figures given by the "ps -o vsr,rss" command.

For the moment, I make a popen("ps...") followed of a scanf on what it
displays. It is a little complicated, and that distorts measurements.
Is there a better way?

I have tried "getrusage()". However values returned are not really
relevant for my needs.

I also looked at "mallinfo()", without success.
First, I do not know what is that a "block" (which size ?). Then, that does
not count the stack size and the code size, just the malloc.
(By the way, it's more or less a C++ code. So, are the "new" counted in
mallinfo() ?)

Then, how can my program know its "resident set size" and especially its
"virtual memory size"?

Thanks.
Christophe

 

[Artie Gold]

Hi,

Inside a program, I need to get some statistics about memory usage.
I actually need figures given by the "ps -o vsr,rss" command.

For the moment, I make a popen("ps...") followed of a scanf on what it
displays. It is a little complicated, and that distorts measurements.
Is there a better way?

I have tried "getrusage()". However values returned are not really
relevant for my needs.

I also looked at "mallinfo()", without success.
First, I do not know what is that a "block" (which size ?). Then, that does
not count the stack size and the code size, just the malloc.
(By the way, it's more or less a C++ code. So, are the "new" counted in
mallinfo() ?)

Then, how can my program know its "resident set size" and especially its
"virtual memory size"?

Thanks.
Christophe

The C language itself knows not of such things. Is is likely, however,
that your platform provides some way of getting such information (likely
in a reasonable way) <hint, hint>. See your documentation or post to a
relevant newsgroup.

HTH,
--ag

 

[David Resnick]

Hi,

Inside a program, I need to get some statistics about memory usage.
I actually need figures given by the "ps -o vsr,rss" command.

For the moment, I make a popen("ps...") followed of a scanf on what it
displays. It is a little complicated, and that distorts measurements.
Is there a better way?

I have tried "getrusage()". However values returned are not really
relevant for my needs.

I also looked at "mallinfo()", without success.
First, I do not know what is that a "block" (which size ?). Then, that does
not count the stack size and the code size, just the malloc.
(By the way, it's more or less a C++ code. So, are the "new" counted in
mallinfo() ?)

Then, how can my program know its "resident set size" and especially its
"virtual memory size"?

Thanks.
Christophe

This is all system specific, so OT in comp.lang.c. From what you are
saying,
I believe comp.unix.programmer would be a good place for you to get
help. <OT> On Linux, May find what you want in /proc file system, you
could ask about that in cup </OT>

-David

 

[Keith Thompson]

This is all system specific, so OT in comp.lang.c. From what you are
saying,
I believe comp.unix.programmer would be a good place for you to get
help. <OT> On Linux, May find what you want in /proc file system, you
could ask about that in cup </OT>

<STILL_OT>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</STILL_OT>

 

[Kenny McCormack]

<STILL_OT>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</STILL_OT>

That should have been:

<WRONG>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</WRONG>

Solaris has /proc, as do (I believe) over Unix flavors.

 

[Kenny McCormack]

Hi,

Inside a program, I need to get some statistics about memory usage.
I actually need figures given by the "ps -o vsr,rss" command.

For the moment, I make a popen("ps...") followed of a scanf on what it
displays. It is a little complicated, and that distorts measurements.
Is there a better way?

Allow me to be the first to say this - and I say it from the deepness of my
heart, with all the kindness and love one has come to associate with the
helpful posts you get in this newsgroup:

Not portable. Can't discuss it here. Blah, blah, blah.

 

[Flash Gordon]

That should have been:

<WRONG>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</WRONG>

No, what Keith said is correct.

Solaris has /proc, as do (I believe) over Unix flavors.

Are you claiming that these Unix flavours are not like Unix?

 

[Keith Thompson]

That should have been:

<WRONG>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</WRONG>

Solaris has /proc, as do (I believe) over Unix flavors.

With a *very* different interface, the details of which are, of
course, best discussed elsewhere. Followups to /dev/null.

 

[Joe Estock]

Kenny McCormack wrote:
[usual crap]

You're still alive Kenny? I thought someone would have killfiled you by now.

Joe

 

[Mark B]

[...]
This is all system specific, so OT in comp.lang.c. From what you are
saying,
I believe comp.unix.programmer would be a good place for you to get
help. <OT> On Linux, May find what you want in /proc file system, you
could ask about that in cup </OT>
<STILL_OT>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</STILL_OT>

That should have been:

<WRONG>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</WRONG>

No, what Keith said is correct.

Actually, what Keith said is most definately NOT correct.

Are you claiming that these Unix flavours are not like Unix?

No, his claim is that: /proc is NOT linux specific... and he is right.
Many systems (which predate Linux) also use(d) a /proc file system.

 

[Jordan Abel]

Kenny McCormack wrote:
[usual crap]

You're still alive Kenny? I thought someone would have killfiled you by now.

You know - i don't think you understand how a "killfile" works. It
blocks him from being seen by the person who sets the killfile entry,
unless someone else [you] responds to him. If you want him gone, _you_
have to "killfile" him [i'm not sure how thunderbird 1.0.9 does it, but
surely there's some way to ignore or mark-as-read based on from address]

 

[Keith Thompson]

[...]
This is all system specific, so OT in comp.lang.c. From what you are
saying,
I believe comp.unix.programmer would be a good place for you to get
help. <OT> On Linux, May find what you want in /proc file system, you
could ask about that in cup </OT>
<STILL_OT>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</STILL_OT>

That should have been:

<WRONG>
/proc is Linux-specific, though some other Unix-like systems may
provide something similar.
</WRONG>

No, what Keith said is correct.

Actually, what Keith said is most definately NOT correct.

Are you claiming that these Unix flavours are not like Unix?

No, his claim is that: /proc is NOT linux specific... and he is right.
Many systems (which predate Linux) also use(d) a /proc file system.

Sigh.

My wording was slightly sloppy. The existence of /proc is not
Linux-specific. The details of the interface of /proc *are*, as far
as I know, Linux-specific (and/or specific to the system in question).
My intent was merely to suggest that cup (comp.unix.programmer) is not
the best place to discuss /proc, since it covers systems with widely
varying /proc interfaces (or none at all, at least for some older
systems). The details of /proc would be topical in one of the
comp.os.linux.* groups, or in comp.unix.solaris, or comp.unix.aix, or
whatever.

This is tangentially topical here only insofar as we're trying to
determine the best newsgroup to which to redirect the original poster
(who is probably long gone by now).

 

[John Devereux]

Kenny McCormack wrote:
[usual crap]

You're still alive Kenny? I thought someone would have killfiled you by now.

Oh no! They killed Kenny!

 

[Kenny McCormack]

Kenny McCormack wrote:
[usual crap]

You're still alive Kenny? I thought someone would have killfiled you by now.

Joe

Like a bad penny...

 

[Mark McIntyre]

Howevr what solaris puts in /proc is rather different.

Are you claiming that these Unix flavours are not like Unix?

I think keith's point was that the contents of /proc are
operating-system specific.

 

[Kenny McCormack]

Howevr what solaris puts in /proc is rather different.


I think keith's point was that the contents of /proc are
operating-system specific.

Which is the same as saying that trees are North-America-specific, because
our trees are different from the trees that grow in other parts of the
world.

Note that, ordinarily, I'd cut him some slack - it's late, his phrasing was
inexact - but this is clc where what we do is stomp on people for any
possible error, no matter how microscopic. That's the game we play here,
and I like it!

 

[Chris McDonald]

On Fri, 02 Dec 2005 20:17:37 +0000, in comp.lang.c , Flash Gordon

Howevr what solaris puts in /proc is rather different.

I think keith's point was that the contents of /proc are
operating-system specific.

It's very interesting to note that the first reply to this topic was
someone quickly highlighting how off-topic the topic was. The OP has
since moved on to comp.unix.programmer, and received a helpful reply.

Since then, we've seen about a dozen articles, some from old hands,
continuing a debate about exactly what is, and what is not, a
Linux-specific feature.

Just an observation....

 

[pete]

It's very interesting to note that the first reply to this topic was
someone quickly highlighting how off-topic the topic was. The OP has
since moved on to comp.unix.programmer, and received a helpful reply.

Since then, we've seen about a dozen articles, some from old hands,
continuing a debate about exactly what is, and what is not, a
Linux-specific feature.

Just an observation....

I was thinking the same thing.

"The off topic argument"

 

[Kenny McCormack]

It's very interesting to note that the first reply to this topic was
someone quickly highlighting how off-topic the topic was. The OP has
since moved on to comp.unix.programmer, and received a helpful reply.

Since then, we've seen about a dozen articles, some from old hands,
continuing a debate about exactly what is, and what is not, a
Linux-specific feature.

It's what we do. We're not allowed to talk about anything substantive, so
this is what we do.

Just an observation....

And a good one.

 

[Joe Estock]

Kenny McCormack wrote:
[usual crap]

You're still alive Kenny? I thought someone would have killfiled you by now.

You know - i don't think you understand how a "killfile" works. It
blocks him from being seen by the person who sets the killfile entry,
unless someone else [you] responds to him. If you want him gone, _you_
have to "killfile" him [i'm not sure how thunderbird 1.0.9 does it, but
surely there's some way to ignore or mark-as-read based on from address]

Thanks for the clarification Jordan. I was under the presumption that a
killfile was controlled server side not client side.

Joe