From: Pete Wyckoff <pw@osc.edu>
To: Dan Kegel <dank@kegel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: getrusage vs /proc/pid/stat?
Date: Mon, 18 Jun 2001 13:44:33 -0400 [thread overview]
Message-ID: <20010618134433.C9415@osc.edu> (raw)
In-Reply-To: <3B2D8ED0.40B299B5@kegel.com>
In-Reply-To: <3B2D8ED0.40B299B5@kegel.com>; from dank@kegel.com on Sun, Jun 17, 2001 at 10:17:04PM -0700
dank@kegel.com said:
> I'd like to monitor CPU, memory, and I/O utilization in a
> long-running multithreaded daemon under kernels 2.2, 2.4,
> and possibly also Solaris (#ifdefs are ok).
>
> getrusage() looked promising, and might even work for CPU utilization.
> Dunno if it returns info for all child threads yet, haven't tried it.
> In Linux, though, getrusage() doesn't return any info about RAM.
>
> I know I can get the RSS and VSIZE under Linux by parsing /proc/pid/stat,
> but was hoping for a faster interface (although I suppose a seek,
> a read, and an ascii parse isn't *that* slow). Is /proc/pid/stat
> the only way to go under Linux to monitor RSS?
getrusage() isn't really the system call you want for this.
There is a max RSS value, which linux could support but doesn't, but
you seem to want to see the current RSS over time. Search the archive
for various patches/complaints about getrusage.
For vsize, most OSes offer time-integral averages of text, data, and
stack sizes via getrusage(). Again, more of an aggregate than a current
snapshot, and again, linux returns zero for these currently.
-- Pete
next prev parent reply other threads:[~2001-06-18 17:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-18 5:17 getrusage vs /proc/pid/stat? Dan Kegel
2001-06-18 17:44 ` Pete Wyckoff [this message]
2001-06-18 21:20 ` Dan Kegel
2001-06-18 23:34 ` J . A . Magallon
2001-06-19 15:05 ` Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010618134433.C9415@osc.edu \
--to=pw@osc.edu \
--cc=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.