httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: httpd-trunk sucking CPU on ajax
Date Mon, 27 Feb 2006 08:55:47 GMT
On Sun, Feb 26, 2006 at 11:55:31PM -0800, Sander Temme wrote:
> (gdb) bt
> #0  allocator_free (allocator=0x6000000000167ad0,  
> node=0x6000000000186e80)
>     at ../../../apr/memory/unix/apr_pools.c:343
> #1  0x20000000003b6540 in apr_pool_destroy (pool=0x6000000000186ea8)
>     at ../../../apr/memory/unix/apr_pools.c:769
> #2  0x400000000004ae20 in eor_bucket_destroy (data=0x6000000000186f18)
>     at /home/jerenkrantz/work/httpd-trunk/server/eor_bucket.c:52
> #3  0x20000000000eef90 in apr_brigade_cleanup (data=0x600000000016aae8)
>     at ../../../apr-util/buckets/apr_brigade.c:44
> #4  0x20000000000eeec0 in brigade_cleanup (data=0x600000000016aae8)
>     at ../../../apr-util/buckets/apr_brigade.c:34
> #5  0x20000000003b77a0 in run_cleanups (cref=0x6000000000169be8)
>     at ../../../apr/memory/unix/apr_pools.c:2044
> #6  0x20000000003b62e0 in apr_pool_clear (pool=0x6000000000169bc8)
>     at ../../../apr/memory/unix/apr_pools.c:689
> #7  0x40000000000746d0 in child_main (child_num_arg=118704)
>     at /home/jerenkrantz/work/httpd-trunk/server/mpm/prefork/ 
> prefork.c:467
> #8  0x4000000000074de0 in make_child (s=0x6000000000023790, slot=100)
>     at /home/jerenkrantz/work/httpd-trunk/server/mpm/prefork/ 
> prefork.c:736
> #9  0x4000000000074fc0 in startup_children (number_to_start=49)
>     at /home/jerenkrantz/work/httpd-trunk/server/mpm/prefork/ 
> prefork.c:747
> #10 0x4000000000076740 in ap_mpm_run (_pconf=0x0,  
> plog=0x600000000004e2a8,
>     s=0x6000000000023790)
>     at /home/jerenkrantz/work/httpd-trunk/server/mpm/prefork/ 
> prefork.c:975
> #11 0x4000000000025ad0 in main (argc=2, argv=0x60000fffffffaf68)
>     at /home/jerenkrantz/work/httpd-trunk/server/main.c:712
> 
> I don't see a request record anywhere, so I can't really tell if any  
> of these CPU hogs have a reproducible history. However, I have seen  
> this before on this codebase on this CPU and it looks like they're  
> stuck in a tight loop in apr/memory/unix/apr_pools.c...
> 
> Perhaps this merits a closer look.

Initial thought is that we're clearing the request pool when we've already
cleared it.  The line numbers on that version of gcc suck, but the only
pool_clear would be at line 547 which clears the child's ptrans pool.

But, in the eor_bucket_destroy, it tries to clear the request pool.  By the
time we get here though, apr's already killed off our sub pools - including
the request pool.  Oops.

The data flag from the eor_bucket_destroy is the request_rec.  One that I'm
seeing in the loop is:

(gdb) print *(request_rec*)data
$3 = {pool = 0x600000000019aeb8, connection = 0x6000000000169e28, 
  server = 0x60000000000edfb8, next = 0x0, prev = 0x0, main = 0x0, 
  the_request = 0x600000000019c568 "GET /bugzilla/show_bug.cgi?id=36525 HTTP/1.1", assbackwards
= 0, proxyreq = 0, header_only = 0, 
  protocol = 0x600000000019c628 "HTTP/1.1", proto_num = 1001, 
  hostname = 0x600000000019c988 "issues.apache.org", 
  request_time = 1141027089261002, status_line = 0x400000000008f288 "200 OK", 

> Maybe we should run this instance niced?

Nah, we should fix the problem instead.  =P  -- justin

Mime
View raw message