if you are seeing leaks while using apr memory allocation, it's better to use apache pool debug
i am just pasting some portion of the debug logs which i used to debug issue, this might help you. In the following "request" means that you are allocated memory from request processing for given connection. "proxy_conn_pool" means allocation happened from proxy connection pool. I have found this is best approach to find leaks or allocation procedure of apache. -thanks Harish POOL DEBUG: [14983/3058834320] PALLOC ( 4463/ 4463/ 143668) 0x80ffee0 "request" <strings/apr_strings.c:149> (67/67/0) POOL DEBUG: [14983/3058834320] PALLOC ( 81/ 81/ 143685) 0x814c038 "proxy_conn_pool" <strings/apr_strings.c:78> (2/7/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 249/ 249/ 143853) 0x814c038 "proxy_conn_pool" <network_io/unix/sockaddr.c:388> (3/8/1) POOL DEBUG: [14983/3058834320] PALLOC ( 266/ 266/ 143870) 0x814c038 "proxy_conn_pool" <strings/apr_strings.c:78> (4/9/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 434/ 434/ 144038) 0x814c038 "proxy_conn_pool" <network_io/unix/sockaddr.c:388> (5/10/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 602/ 602/ 144206) 0x814c038 "proxy_conn_pool" <network_io/unix/sockaddr.c:388> (6/11/1) [Thu Jan 15 13:44:51 2009] [debug] proxy_util.c(2195): proxy: connected / to www.google.co.in:80 POOL DEBUG: [14983/3058834320] PCALLOC ( 56/ 56/ 144262) 0x814c098 "proxy_conn_scpool" <network_io/unix/sockets.c:61> (1/1/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 224/ 224/ 144430) 0x814c098 "proxy_conn_scpool" <network_io/unix/sockets.c:64> (2/2/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 392/ 392/ 144598) 0x814c098 "proxy_conn_scpool" <network_io/unix/sockets.c:67> (3/3/1) POOL DEBUG: [14983/3058834320] PALLOC ( 408/ 408/ 144614) 0x814c098 "proxy_conn_scpool" <memory/unix/apr_pools.c:2177> (4/4/1) [Thu Jan 15 13:44:51 2009] [debug] proxy_util.c(2401): proxy: HTTP: fam 2 socket created to connect to * POOL DEBUG: [14983/3058834320] PALLOC ( 424/ 424/ 144630) 0x814c098 "proxy_conn_scpool" <memory/unix/apr_pools.c:2177> (5/5/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 520/ 520/ 144726) 0x814c098 "proxy_conn_scpool" <core.c:3875> (6/6/1) POOL DEBUG: [14983/3058834320] PCALLOC ( 1172/ 1172/ 145378) 0x814c098 "proxy_conn_scpool" <config.c:210> (7/7/1) POOL DEBUG: [14983/3058834320] PALLOC ( 1452/ 1452/ 145658) 0x814c098 "proxy_conn_scpool" <tables/apr_tables.c:394> (8/8/1) POOL DEBUG: [14983/3058834320] PALLOC ( 1512/ 1512/ 145718) 0x814c098 "proxy_conn_scpool" <tables/apr_tables.c:69> (9/9/1) POOL DEBUG: [14983/3058834320] PALLOC ( 1528/ 1528/ 145734) 0x814c098 "proxy_conn_scpool" <network_io/unix/sockaddr.c:128> (10/10/1) POOL DEBUG: [14983/3058834320] PALLOC ( 618/ 2146/ 145750) 0x814c038 "proxy_conn_pool" <network_io/unix/sockaddr.c:128> (7/12/1) [Thu Jan 15 13:44:51 2009] [debug] proxy_util.c(2502): proxy: HTTP: connection complete to 64.233.161.147:80 (www.google.co.in) POOL DEBUG: [14983/3058834320] PALLOC ( 1544/ 1544/ 145766) 0x814c098 "proxy_conn_scpool" <core.c:3916> (11/11/1) POOL DEBUG: [14983/3058834320] PALLOC ( 1564/ 1564/ 145786) 0x814c098 "proxy_conn_scpool" <util_filter.c:283> (12/12/1) POOL DEBUG: [14983/3058834320] PALLOC ( 1584/ 1584/ 145806) 0x814c098 "proxy_conn_scpool" <util_filter.c:283> (13/13/1) POOL DEBUG: [14983/3058834320] PALLOC ( 4479/ 4479/ 145822) 0x80ffee0 "request" <buckets/apr_brigade.c:61> (68/68/0) POOL DEBUG: [14983/3058834320] PALLOC ( 4496/ 4496/ 145839) 0x80ffee0 "request" <strings/apr_strings.c:149> (69/69/0) POOL DEBUG: [14983/3058834320] PALLOC ( 4512/ 4512/ 145855) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (70/70/0) POOL DEBUG: [14983/3058834320] PALLOC ( 4537/ 4537/ 145880) 0x80ffee0 "request" <strings/apr_strings.c:149> (71/71/0) POOL DEBUG: [14983/3058834320] PALLOC ( 4553/ 4553/ 145896) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (72/72/0) POOL DEBUG: [14983/3058834320] PALLOC ( 4897/ 4897/ 146240) 0x80ffee0 "request" <tables/apr_tables.c:406> (73/73/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5197/ 5197/ 146540) 0x80ffee0 "request" <tables/apr_tables.c:69> (74/74/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5218/ 5218/ 146561) 0x80ffee0 "request" <strings/apr_strings.c:149> (75/75/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5234/ 5234/ 146577) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (76/76/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5250/ 5250/ 146593) 0x80ffee0 "request" <buckets/apr_brigade.c:61> (77/77/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5266/ 5266/ 146609) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (78/78/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5282/ 5282/ 146625) 0x80ffee0 "request" <buckets/apr_brigade.c:61> (79/79/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5298/ 5298/ 146641) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (80/80/0) POOL DEBUG: [14983/3058834320] PCALLOC ( 5378/ 5378/ 146721) 0x80ffee0 "request" <http_filters.c:232> (81/81/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5394/ 5394/ 146737) 0x80ffee0 "request" <buckets/apr_brigade.c:61> (82/82/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5410/ 5410/ 146753) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (83/83/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5435/ 5435/ 146778) 0x80ffee0 "request" <strings/apr_strings.c:78> (84/84/0) POOL DEBUG: [14983/3058834320] PALLOC ( 5451/ 5451/ 146794) 0x80ffee0 "request" <memory/unix/apr_pools.c:2177> (85/85/0) POOL DEBUG: [14983/3058834320] PCALLOC ( 1592/ 1592/ 146802) 0x814c098 "proxy_conn_scpool" <core_filters.c:546> (14/14/1) POOL DEBUG: [14983/3058834320] PALLOC ( 5467/ 5467/ 146818) 0x80ffee0 "request" <buckets/apr_brigade.c:61> (86/86/0) On Wed, Feb 17, 2010 at 9:40 PM, Joe Orton <[email protected]> wrote: > On Wed, Feb 17, 2010 at 09:12:03AM -0500, Jeff Trawick wrote: > > a. get the server to steady state > ... > > b. see what causes the heap to expand (brk/sbrk) > > This is what I do too, FWIW. It's primitive but usually effective. > > Regards, Joe > >
