[dtrace-discuss] Getting total memory allocated so far

rickey c weisner
Thu, 03 Jan 2008 15:26:54 -0000

If you are wanting heap size or rss then.
man -s 4 proc
pstatus_t structure, status  file
           size_t pr_brksize;       /* size of the process heap, in bytes */
and
psinfo_t,  psinfo file
          size_t pr_rssize;        /* resident set size in Kbytes */

Contact me offline if you would like sample code.
But pmap -x gives you all that already.
rick

On Thu, Jan 03, 2008 at 02:15:48AM -0500, Lally Singh
wrote:
> Date: Thu, 03 Jan 2008 02:15:48 -0500
> From: Lally Singh <lally.singh at gmail.com>
> Subject: Re: [dtrace-discuss] Getting total memory allocated so far
> In-reply-to: <18299.55046.472427.139710 at gargle.gargle.HOWL>
> To: James Carlson <James.D.Carlson at Sun.COM>, jgh at wizmail.org
> Cc: dtrace-discuss at opensolaris.org, Jim Mauro <James.Mauro at
Sun.COM>
> Errors-to: dtrace-discuss-bounces at opensolaris.org
> Precedence: list
> X-BeenThere: dtrace-discuss at opensolaris.org
> Delivered-to: dtrace-discuss at opensolaris.org
> X-PMX-Version: 5.2.0.264296
> X-Brightmail-Tracker: AAAAAA=> X-Spam-Checker-Version: SpamAssassin
3.2.3 (2007-08-08) on
> 	oss-mail1.opensolaris.org
> X-Original-To: dtrace-discuss at opensolaris.org
> X-Antispam: No, score=-0.4/5.0, scanned in 0.056sec at (localhost
[127.0.0.1])
> 	by smf-spamd v1.3.1 - http://smfs.sf.net/
> X-Mailman-Version: 2.1.9
> List-Post: <mailto:dtrace-discuss at opensolaris.org>
> List-Subscribe:
<http://mail.opensolaris.org/mailman/listinfo/dtrace-discuss>,
> 	<mailto:dtrace-discuss-request at opensolaris.org?subject=subscribe>
> List-Unsubscribe:
>  <http://mail.opensolaris.org/mailman/listinfo/dtrace-discuss>,
> 	<mailto:dtrace-discuss-request at
opensolaris.org?subject=unsubscribe>
> List-Archive: <http://mail.opensolaris.org/pipermail/dtrace-discuss>
> List-Help: <mailto:dtrace-discuss-request at
opensolaris.org?subject=help>
> List-Id: DTrace General Discussion <dtrace-discuss.opensolaris.org>
> X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=unavailable
> 	version=3.2.3
> X-Spam-Level:
>
> @Jeremy: yeah, I''m tracking how much memory it''s actually
using right
> now.. sbrk makes it complicated, but I figure that more advanced
> memory management may help, once I''ve measured how it''s
getting used
> today.  Via mmap() for large transient allocations and/or some
> smartness about allocating smartly to keep the working set of pages
> reasonable.
>
> @James: I saw that, but could I use it on a running program without
> stopping it?  The dtrace scripts don''t do much damage, and the
program
> still gets all its work done at ~60 Hz for its clients.  Single
> threaded, no less.
>
> Some more details: I was trying to keep this all a simple question,
> but with memory there rarely are simple questions.  My research is on
> the scalability of massively multiplayer online games.  So, I''ve
> written a load simulator which logs in from remote computers and
> starts playing the game.  I''ve got a bunch of dtrace scripts that
> measure the network, memory, and cpu usage as I add more simulated
> clients.  The scripts haven''t shown themselves to interfere
> significantly with performance (yet), but in exchange they put out
> data once a second, which another script reads & shoves into a db for
> me.
>
> I''d like to monitor memory usage without interfering with my other
> measurements.  Hence, I''d love to know something close to a global
var
> (which''d be great, malloc() already has to do some locking (for
normal
> malloc, haven''t seen umem), so why not?) or some way to quickly
> assemble a running total.  Right now all I''ve got is a pid
provider
> probe for malloc & free that reads the headers on the memory blocks
> they use.
>
> Thanks in advance everyone!
>
> On Jan 2, 2008 1:25 PM, James Carlson <james.d.carlson at sun.com>
wrote:
> > Lally Singh writes:
> > > I''d like to track to total amount of memory the
application''s actually
> > > using right now.   More specifically, I guess these rules would
do it:
> > >
> > > 1. start at M=0
> > > 2. for each call to malloc(): set M += size of block returned by
malloc
> > > 3. for each call to free(): set M -= size of block freed.
> >
> > Using "env LD_PRELOAD=libumem.so myapp" with mdb''s
umem support should
> > get you that (plus quite a bit more).
> >
> > --
> > James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
> > Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442
2084
> > MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442
1677
> >
>
>
>
> --
> H. Lally Singh
> Ph.D. Candidate, Computer Science
> Virginia Tech
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--

Rickey C. Weisner
Software Development and Performance Specialist
Sun Microsystems, INC
cell phone: 615-308-1147
email: rick.weisner at sun.com