Date: Thu, 30 Jan 2003 11:41:36 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: James Gritton <gritton@iserver.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: What's the memory footprint of a set of processes? Message-ID: <200301301941.h0UJfa0e089230@apollo.backplane.com> References: <Pine.BSF.4.21.0301291145030.25856-100000@InterJet.elischer.org> <x7k7gnog4m.fsf@guppy.dmz.orem.verio.net> <20030130064448.GA7258@HAL9000.homeunix.com> <200301300719.h0U7JOfI086054@apollo.backplane.com> <x7znpi60hd.fsf@guppy.dmz.orem.verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I just had another idea on how you could do this. It's actually not
all that complex.
All you do is collect statistics on each VM object individually
(whether shadow or top level or whatever). e.g. Resident page count,
swap usage.
Then you collect a list of VM objects associated with a process,
regardless of HOW they are associated. Recurse through the
vm_map_entry's and the shadow chains to get the list.
Then you simply group all the processes which share VM
objects together and report statistics on a group-by-group basis
rather then on a process-by-process basis. You won't know what an
individual process uses but you know exactly what the group of
processes use in aggregate.
Groups of processes will tend to form due to fork()ing, processes
sharing memory via SysV shared memory, and processes that happen
to be mapping the same file (vnode). You will get accurate memory
use for each group.
-Matt
: Actually, that's just the sort of thing I'm looking for. The shared case
:may be relatively rare, but it tends to be extreme: the processes that use
:the most memory seem to be the ones that fork the most - database servers,
:java, etc. The point of this whole thing is an attempt to limit the memory
:use of a user (instead of a process), but I don't want to penalize such
:sharing.
:
:..
: That's OK - resident count is what I'm interested in. That, and the swap
:approximation (which should suffice) you mentioned for non-vnode objects.
:
:- Jamie
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301301941.h0UJfa0e089230>