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.

Reply via email to