You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Daniel B. Hemmerich" <da...@webclients.net> on 2006/09/01 17:15:37 UTC
Memory Usage
We are concerned about how much memory we are using now that we are moving
to modperl.
Are there any good tools/procedures that we could use to determine how much
memory our application is currently using - and then using that as a
benchmark, determine how much more or less memory we are using after making
changes to our application?
This is not directly a modperl question - but maybe there are some handy
tools that are closely tied to modperl.
Thanks in advance!
Re: Memory Usage
Posted by Tobias Kremer <t...@funkreich.de>.
I suggest taking a look at the excellent mod_perl performance guide:
http://perl.apache.org/docs/1.0/guide/performance.html
-- Tobias
Zitat von "Daniel B. Hemmerich" <da...@webclients.net>:
> We are concerned about how much memory we are using now that we are moving
> to modperl.
>
>
>
> Are there any good tools/procedures that we could use to determine how much
> memory our application is currently using - and then using that as a
> benchmark, determine how much more or less memory we are using after making
> changes to our application?
>
>
>
> This is not directly a modperl question - but maybe there are some handy
> tools that are closely tied to modperl.
>
>
>
> Thanks in advance!
>
>
Re: Memory Usage
Posted by Jonathan Vanasco <jo...@2xlp.com>.
On Sep 1, 2006, at 11:15 AM, Daniel B. Hemmerich wrote:
> We are concerned about how much memory we are using now that we are
> moving to modperl.
>
> Are there any good tools/procedures that we could use to determine
> how much memory our application is currently using – and then using
> that as a benchmark, determine how much more or less memory we are
> using after making changes to our application?
re: mp performance guide (in previous post) --
its great for perfomance tuning. GTOP works well for the current
memory size.
Iinstall Apache::Status, and all of the bells & whistles to get the
aggregate memory info printed ( i believe that means b::terse size
and recdescent )
None of the modules can accurately measure shared memory
ignore any info re: shared memory. just forget about it. it never
measures right.
the only way to measure shared memory is to watch free/swap memory
and start adding clients/requests, trying to find the point where
memory goes from free to swap ( the 'free' memory seems to be ok in
top , but top can lie. watching your disks swap is a great
indicator that you've maxxed out )
From my recent personal experience (assuming you are on *nix/*bsd,
and using prefork)
run the server with 1 child on start, 1 maxclients, 0 spareservers
-- so you only have the parent and a single child
before you request any pages, note the vitrtual and res size of each
item using 'ps aux'
run apache status, and show the main memory page
i copy-pasted that code into a text document then regexed and
sorted it.
profile your apps based on that, looking for the fattest modules.
if a module is too big for the benefits it gives, axe it
File::Find let me do a recursive search for templates to pre-
compile in 8 lines of code. but it had a 3mb memory overhead. i
replaced it with 15 lines of my own recursive search, that had a 4k
overhead.
on your own modules, replace $debug varaiables with DEBUG
constants so they're compiled away
my session parsing class went from 867k to 240k of memory ( when
DEBUG is off ), and half as many opcodes
compare the loaded modules pre- and post- request. if you're seeing
some modules get loaded after a request has been made, you should
probably load them in a startup.pl
shut down as many non-essential processes as you can on the machine
in question.
open a seperate terminal, run 'top -U www' or whomever your httpd
runs as. note the free system memory before you start apache and after
raise maxclients and startservers to 6, then 11 -- each time
stopping and starting the server. it'll give you an idea of the
memory consumed by 5 and 10 additional clients
make some requests with 1,6,11 clients , either using AB or some
sort of programmatic test suite.
in my experience, using my own framework, i've got this:
60mb parent apache
3mb child on startup
11mb child after 1 request
+0-1.5mb per child per additional URI module (depending on page
complexity)
there's a slight growth per-child-per-request as well if you're
using DBI -- DBI caches 120 SVs internally for statement handles PER
CHILD. they don't get released until a counter hits 120, then it
goes up again.