Date: Thu, 4 Sep 2003 13:40:52 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jesse Guardiani <jesse@wingnet.net> Cc: freebsd-questions@freebsd.org Subject: Re: fwe in production? fwe bandwidth? Message-ID: <20030904124052.GD88888@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <bj5rcl$3r5$4@sea.gmane.org> References: <bj5rcl$3r5$4@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 03, 2003 at 06:53:09PM -0400, Jesse Guardiani wrote: > Howdy list, >=20 > I'm a Sys Admin running FreeBSD 4.8-RELEASE > servers. >=20 > During a recent programming/installation > project, I found myself wanting to know > the peak memory usage of a given command/process. >=20 > Is there any way to gather this information > without recompiling an application with a > sleep or wait statement at the (assumed) > point of peak memory usage and then looking > at the process with 'ps'? That depends on exactly how much time you've got to record the peak memory usage. If it's going to be changing faster than you could catch just by running ps(1) -- like: % ps -p NNN -o rsz where NNN is the pid of your process, then you're probably going to have to interrupt the process somehow. You can do that by attaching to the process using gdb(1), eg: % gdb PROGNAME NNN this will stop the process and leave you in the debugger at the current program counter. You'ld have to create a break point when the program calls malloc(3) or friends, continue running until it hits the break point, step over the malloc call, check the size using ps(1), and then continue running again until the next malloc(3) call. Repeat until the program ends. See the gdb info pages for the gory details. Nb. this whole thing with gdb(1) is going to be a great deal easier if you have the source code to your program available and you can run an unstripped binary. Doing such a trick on a stripped binary is getting into real guru territory. Programs run a lot slower when attached in a debugger, plus if the program makes heavy use of malloc, it's going to get really tedious very quickly. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/VzLUdtESqEQa7a0RAkhPAJ9Ds3UKIw5R5VSeek8m+DOGmcW/SQCfcNOV 1G8ewFmBTCGRXWzqDxO6MVI= =cqAx -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030904124052.GD88888>