DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44026>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44026 ------- Additional Comments From [EMAIL PROTECTED] 2007-12-20 00:24 ------- (In reply to comment #36) > Some new results: > > 1. I cannot run apache under high load with the debug logging turned on. The > logging itself is too resource intensive in order to get meaningful results > (Apache server very quckly becomes completely unresponsive) I already feared this :-(. Thanks for trying anyway. > > 2. I tried the new patch for about 15 minutes during which RSS hit about > 800mb. > This number was still growing at a constant rate at the end of the test. The > test was stopped after 15 minutes since I cannot run a simple forward proxy > for > long in production. The number of simultaneous connections was about 600. Ok. Lets have some estimation of what RSS can be expected for all processes together: 1. You already set the stacksize per thread to 256k 2. I think it is not unreasonable to expect that each thread that was / is in use consumes about 128k heap. Given your settings this should result in 8 * 512 * (256 + 128)k = 1572864 k = 1536 MB = 1.5 GB So you should not expect your RSS consumption below that. The virtual consumption will be somewhat higher as we need to add the MMAPed binaries for each process. Of course this is still a lot away from the 10 GB you have seen. > > 3. I also tried running with my custom Apache module. In this case memory > consumption grows about 10x as quickly than without it. This is the case even > if > the module is reduced to nothing but passing brigades through itself. This seems to be a hint that something is wrong with your custom module. As you say it passes brigades I assume it is a filter. Please have a look at http://httpd.apache.org/docs/trunk/en/developer/output-filters.html and check if your code follows these guidelines. > > Please let let me know what other info I can provide. I am a little bit lost now. My only idea is to reduce the number of debug messages printed. So please try the following patch for apr: Index: memory/unix/apr_pools.c =================================================================== --- memory/unix/apr_pools.c (revision 598762) +++ memory/unix/apr_pools.c (working copy) @@ -493,6 +493,7 @@ unsigned int stat_alloc; unsigned int stat_total_alloc; unsigned int stat_clear; + unsigned int print_count; #if APR_HAS_THREADS apr_os_thread_t owner; apr_thread_mutex_t *mutex; @@ -1125,6 +1126,12 @@ static void apr_pool_log_event(apr_pool_t *pool, const char *event, const char *file_line, int deref) { + if (pool->print_count++ < APR_PRINT_COUNT) { + return; + } + else { + pool->print_count = 0; + } if (file_stderr) { if (deref) { apr_file_printf(file_stderr, and recompile httpd / APR with make clean CFLAGS="-O2 -g -Wall -DAPR_POOL_DEBUG=16 -DAPR_PRINT_COUNT=100" ./configure <whatever your options are> make make install Feel free to increase the value of APR_PRINT_COUNT to 1000 or whatever is needed to keep your httpd running with load. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
