Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
On Fri, 2007-10-05 at 15:37 +1000, Bojan Smojver wrote: - make conn-pool have/own its own allocator - destroy, rather then clear conn-pool on connection close Example patch attached. -- Bojan --- httpd-2.2.6/server/core.c 2007-08-07 22:12:20.0 +1000 +++

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
On Fri, 2007-10-05 at 16:06 +1000, Bojan Smojver wrote: Example patch attached. Sorry, that patch is seriously brain dead. I'll try modifying the prefork.c instead, which seems like a better place to do it. Keep you posted... -- Bojan

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
On Fri, 2007-10-05 at 15:37 +1000, Bojan Smojver wrote: I noticed that if a large number of buckets in a brigade are sent out, the resident memory footprint of httpd process (been playing with 2.2.6 for now) will go up significantly. I didn't mention this before, but MaxMemFree directive

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
On Fri, 2007-10-05 at 16:56 +1000, Bojan Smojver wrote: Keep you posted... Another approach attached. -- Bojan --- server/mpm/prefork/prefork.c 2007-10-05 17:27:13.0 +1000 +++ server/mpm/prefork/prefork.c.patched 2007-10-05 17:14:25.0 +1000 @@ -465,7 +465,7 @@ static void

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Joe Orton
On Fri, Oct 05, 2007 at 03:37:57PM +1000, Bojan Smojver wrote: Now imagine someone (like yours truly :-) writing a handler/filter that sends many, many buckets inside a brigade down the filter chain. This causes the httpd process to start consuming many, many megabytes (in some instances I

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
Quoting Aleksey Midenkov [EMAIL PROTECTED]: And what if a large file is downloaded and processed by filters? Did the buckets allocated by filters will not be deallocated until the connection end? This can be a cause of DOS. The buckets should be freed after they have flushed out of

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Aleksey Midenkov
And what if a large file is downloaded and processed by filters? Did the buckets allocated by filters will not be deallocated until the connection end? This can be a cause of DOS. The buckets should be freed after they have flushed out of ap_core_output_filter. On Friday 05 October 2007

Re: Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-05 Thread Bojan Smojver
Quoting Joe Orton [EMAIL PROTECTED]: It sounds like that is the root cause. If you create a brigade with N buckets in for arbitrary values of N, expect maximum memory consumption to be O(N). The output filtering guide touches on this:

Cleanup/desctruction of connection pool and associated bucket_alloc

2007-10-04 Thread Bojan Smojver
I noticed that if a large number of buckets in a brigade are sent out, the resident memory footprint of httpd process (been playing with 2.2.6 for now) will go up significantly. For instance, one could replicate this behaviour by having a file processed by the INCLUDES filter, which contains a