SCIENTIFIC-LINUX-USERS Archives

April 2010

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Brett Viren <[log in to unmask]>
Reply To:
Brett Viren <[log in to unmask]>
Date:
Wed, 28 Apr 2010 14:21:24 -0400
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (975 bytes) , smime.p7s (1762 bytes)
Thanks Stephan and Peter,

Peter Elmer <[log in to unmask]> writes:

> We are actually preparing some proposals/recommendations about
> measuring memory use, as in addition to this VSIZE/64bit confusion the
> introduction of "multicore" applications which share memory also
> misleads people...

This is interesting.  I didn't know about the nuances you two bring up.
Peter, can you send a link whenever your document is available?

Stephan, we have been looking at /proc/PID/status's VmSize and VIRT from
"top" which I think are the same.  

For our Gaudi/Geant4/ROOT/Python based job on 64bits we see a size of
about 1GB after initial loading including Geant4 data sets and the
geometry.  This then plateaus to an eventual 1.5GB as we encounter rarer
and rarer upward fluctuations in event size (our Boost pools based
memory manager only grows as needed, never shrinks).  On 32 bits I'm
used to seeing about 50% of these numbers.

I'll look into the suggestions you both gave.

Thanks,
-Brett.



ATOM RSS1 RSS2