On 06/04/2008 11:45:42 PM +0200, Frank Costanza <[EMAIL PROTECTED]> wrote: > Hi Gabriel, > > I don't mind so much that Apache/mod_fcgid buffers the entire input, but even > after the upload has completed and the input has been passed to the fastcgi > application, Apache has still not freed the memory. Subsequent uploads just > keep adding to the overall Apache memory usage.
I don't know how memory is allocated but uploading a 10MB file in my tests consumed over 100MB in the apache child processing my request. However I hadn't noticed that Apache didn't free the memory after the request was completed, mostly because my test requests never completed. That's serious bugs to fix, but it seems nobody is using fastcgi in the world, or too many lazy people use it and nobody is aware of this list. > > Unfortunately in my situation, I cannot simply tell the system not to use > fastcgi for upload scripts as the system is used to host PHP sites for > customers. I guess my only option at this stage is to limit Apache memory > using ulimit. This is what I do at the moment, but I completely forgot to mention it. Be warned that the usual apache directives to limit resources are not working for the module (RLimitCPU/MEM/NPROC) in spite of the code using APR's own rlimit routines. What I did (and why I forgot) is to add ulimit commands right before starting the httpd process in the apachectl script (that way you always set the limits, even if you apachectl restart). > > > --- On Thu, 5/6/08, Gabriel Barazer <[EMAIL PROTECTED]> wrote: > >> From: Gabriel Barazer <[EMAIL PROTECTED]> >> Subject: Re: [Mod-fcgid-users] Apache consuming all available memory >> To: [EMAIL PROTECTED], mod-fcgid-users@lists.sourceforge.net >> Date: Thursday, 5 June, 2008, 3:05 AM >> Hi, >> >> I have reported that problem about a year ago and yes, this >> is still not >> fixed. Essentially this is because the fix needs _a lot_ of >> changes in >> the module core functions, because the whole logic has to >> be rewritten. >> In the current code, mod_fcgid buffers the entire input >> data before >> testing the input size (which makes MaxRequestLen useless) >> and no data >> can be transmitted to the fastcgi process because it >> doesn't even exist >> yet (the process spawning logic is done after the input >> data is >> buffered). Even though the fastcgi process would already >> exist, the >> input request is not bridged to it before the buffering >> step (meaning: >> you cannot avoid the big memory buffering in any way). >> > > > > __________________________________________________________ > Sent from Yahoo! Mail. > A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
