Re: [dev] [OFFTOPIC] How to know the size of a process?

From: Charlie Kester <corky1951_AT_comcast.net>
Date: Sun, 24 Jan 2010 17:51:45 -0800

On Sun 24 Jan 2010 at 13:48:08 PST Charlie Kester wrote:
>On Sun 24 Jan 2010 at 13:26:56 PST Premysl Hruby wrote:
>>On (24/01/10 13:07), Charlie Kester wrote:
>>>Date: Sun, 24 Jan 2010 13:07:14 -0800
>>>From: Charlie Kester <corky1951_AT_comcast.net>
>>>To: dev_AT_suckless.org
>>>Subject: Re: [dev] [OFFTOPIC] How to know the size of a process?
>>>List-Id: dev mail list <dev.suckless.org>
>>>X-Mailer: Mutt 1.5.20
>>>User-Agent: Mutt/1.5.20 (2009-06-14)
>>>
>>>On Sun 24 Jan 2010 at 09:42:59 PST Premysl Hruby wrote:
>>
>>Shared libraries are not the only shared memory, look for example at
>>dabases (postgres etc) which use enormous blocks of shared memory. Also,
>>you can't simply ignore the shared memory even in case of library, that
>>would highly underestimate your metering.
>
>Good point.

However, on second thought, it doesn't really undercut what I was saying
about things that are called "shared" but really aren't.

If you collect samples of typical system load before and during the
program run, you can use the difference as a fairly reliable estimate of
the additional load the program puts on the system. If the shared
libraries, shared memory or databases really are shared, they'll already
be part of the system load prior to the program run, and can be treated
as if they were part of the OS.

On the other hand, if they aren't already in that typical pre-program
load, I think you'd be justified in counting them as part of the overall
program size. I think this would be true even if you occasionally run
some other programs that use the same stuff. If you never run those
other programs simultaneously with this one, it doesn't matter to the
load calculation that they "share" anything with it.

If the point of the original question wasn't to determine the additional
load caused by a given program, then it would seem to be a merely
academic exercise.
Received on Mon Jan 25 2010 - 01:51:45 UTC

This archive was generated by hypermail 2.2.0 : Mon Jan 25 2010 - 02:00:03 UTC