apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject [PROOF-OF-CONCEPT?] logging memory used by an allocator
Date Wed, 28 Jul 2004 11:33:27 GMT
A couple of questions come up from an application perspective:

am I leaking memory?  if so, on what operation?
how much memory does it take to perform a certain operation?

If the application can find out how much heap memory is presently owned by a 
certain allocator, it can be easier to address such questions.

The attached apr.patch adds apr_allocator_memsize_get() to find the amount of 
heap memory presently owned by the allocator.  (debug pool flavor not 
implemented; what is implemented isn't tested much ;) )

The attached httpd.patch adds %Z log format to mod_log_config to log the memory 
size of the allocator used by the request pool.  (I would lean towards 
implementing this feature in a debug module instead of in mod_log_config.)

The last two fields in the access log below are PID/TID and MEMSIZE.

> "GET / HTTP/1.1" 200 517 23818/5 57448
> "GET / HTTP/1.1" 304 - 23818/5 57448
> "GET /cgi-bin/printenv HTTP/1.1" 200 1241 23818/5 65640
> "GET /cgi-bin/printenv HTTP/1.1" 200 1272 23818/5 65640
> "GET /manual/mod/mod_rewrite.html HTTP/1.1" 200 84992 23819/27 73832
> "GET /manual/style/css/manual.css HTTP/1.1" 200 18172 23819/27 73832
> "GET /manual/style/css/manual-loose-100pc.css HTTP/1.1" 200 2882 23819/27 73832
> "GET /manual/style/css/manual-print.css HTTP/1.1" 200 12977 23818/5 49256
> "GET /manual/images/favicon.ico HTTP/1.1" 200 1078 23819/27 73832
> "GET /manual/images/feather.gif HTTP/1.1" 200 6471 23818/5 49256
> "GET /manual/images/left.gif HTTP/1.1" 200 60 23819/27 73832
> "GET /manual/images/down.gif HTTP/1.1" 200 56 23818/5 49256  <- lower; bug in tracking?
> "GET /manual/images/up.gif HTTP/1.1" 200 57 23819/27 73832
> "GET /manual/images/mod_rewrite_fig1.gif HTTP/1.1" 200 3525 23818/5 49256
> "GET /manual/images/mod_rewrite_fig2.gif HTTP/1.1" 200 2553 23819/27 73832

httpd isn't such a great example of an app where this would be interesting, as 
its pool usage has relatively few surprises.  Other applications in earlier 
stages of development might benefit a lot more.

W.r.t. httpd, there is also an issue that this idea may not help understand bad 
memory behavior when some arbitrary plug-in is active.  Some commercial 
plug-ins are written for multiple web servers and have a relatively small piece 
which is specific to Apache httpd (i.e., which utilizes APR pools), so you 
could still have lots of memory allocated during the processing of certain 
requests without it showing up in the mod_log_config memory trace above.  Any 
ideas for tracking memory usage regardless of how the memory is allocated from 
the heap?  The best I can think of is pretty poor for a threaded server: 
logging the current break value (sbrk()) and hoping for a rough pattern to 
emerge out of lots of data.

Mime
View raw message