mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Greg Bledsoe" <greg.bledsoe@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: pmap, smap, process memory utilization
Date: Tue, 27 Jun 2006 13:40:06 -0500	[thread overview]
Message-ID: <dba10b900606271140o64b60c97kecb8177f801ff9f4@mail.gmail.com> (raw)

Greetings

Our shop runs IBM ldap servers which use a DB2 backend for the data
store.  I and a coworker have been charged with figuring out how much
memory ldap and DB2 are using.  I became nervous, having been down the
"can I get granular memory information" path before.  We came back the
results of watch "free -m" in various scenarios and with the RSS for
the two processes and were asked a lot of questions about the output
of ps and top and what does VSS mean and etc.  I answered with lots of
tedious information on why these tools don't provide an accurate
picture of actual memory utilization due to shared objects, IPC shared
memory, copy on write after forks, and a lot of other factors.  I
responded to short questions with long answers and got frowns in
response.  Capacity planning wants to forecast with more precision
than I can currently offer data for.

To turn those frowns upside down (and satisfy our own curiosity) our idea is to:

Get the map (cat /proc/$PID/maps) with start-stop address ranges for
what that proccess has mapped.

Enumerate the list of all addresses, ie - this process has addresses
1-5 and 9-11; or 1,2,3,4,5,9,10,11 - this process has 1-3 and 12-14,
or 1,2,3,12,13,14

Compare the lists and count each page only once.  So in the above
example only count 1,2,3,4,5,9,10,11,12,13,14 for a total of 11
addresses in use.

This should give a count of each unique memory address, and will avoid
double counting IPC shared memory.  It should be possible to either
include or exclude shared libraries, as desired, and if run
collectively on all processes, should give a total count equal to what
is reported by the "free" command.

I fully expect that there is either something here I don't understand
that prevents this from giving an accurate count, or that I am
duplicating the work someone else has done.

In any case I apologize for the bother and thank you for your time.


-- 
   Greg Bledsoe

    ----------
    I owe my success to having listened respectfully to the very best
advice, and going and doing the exact opposite.
    G.K. Chesterton

             reply	other threads:[~2006-06-27 18:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-27 18:40 Greg Bledsoe [this message]
2006-06-28  9:36 ` Steven Rostedt
2006-06-28 15:55   ` Greg Bledsoe
2006-06-29  6:34     ` Steven Rostedt
2006-06-29 17:46       ` Nick Piggin

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=dba10b900606271140o64b60c97kecb8177f801ff9f4@mail.gmail.com \
    --to=greg.bledsoe@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®