Item1515: fighting back memory leaks when using fastcgi

A long running fastcgi is known to have memory leaks problems of its own as far as I can trust google (which I cant ) mod_fcgid once tried to address this but this project is abandoned for some time now There's a workaround by writing a cron job that regularly checks fcgi memory consumption and sighuping those hogs that grew too fat. That would work out on our current fastcgi engine as it listens to sighups and bails out appropriately.

Adding a maxRequests counter seems to be a nicer solution, a feature that fcgid has got out of the box but not so mod_fastcgi. Once maxRequests have been served, the engine exists the accept loop and re-execs a new process.

Gilmar, tell me what you think when you are up again. See you.

See also Handling Growing FastCGI Processes.

-- MichaelDaum - 24 Apr 2009

We really need this option. Even if core memory leaks are gone, I can't assume extensions to be free of memory leaks.

-- GilmarSantosJr - 24 Apr 2009

Checked in. Waiting for your blessing.

-- MichaelDaum - 24 Apr 2009

Thank you very much, Michael!

I'd only use 0 to disable the feature (like Apache does) and I'll add a Config.Spec to make it appear in configure.

-- GilmarSantosJr - 29 Apr 2009

Did this ever make it into a release? If not, what needs to be done?

-- AndrewJones - 11 Aug 2010

Hi, Andrew. No it was never released. I didn't get the time yet to make the improvements I pointed at the previous comment.

But feel free to do so and release.

-- GilmarSantosJr - 11 Aug 2010

mod_fcgid has got better means to terminate backends. not sure we should leave this feature in.

-- MichaelDaum - 11 Aug 2010

There are a number of reasons why you wouldn't want it started by mod_fcgid (run as different user, restart fcgi server without restarting Apache, using nginx), although they could use spawn-fcgi.

Perhaps the user should be able to pass in the max requests as a parameter to foswiki.fcgi, rather than set it in configure? That would make it optional.

-- AndrewJones - 11 Aug 2010

IMHO, Andrew's point justifies the need to have this feature, and I also like the idea to adjust this setting at command line, instead of $Foswiki::cfg. Default behavior would be to have no limits and let mod_fcgid deal with that. In other setups, the user could adjust according to their needs.

-- GilmarSantosJr - 11 Aug 2010

Ok thanks Gilmar, I will implement this feature and release a new version, hopefully by the weekend.

-- AndrewJones - 11 Aug 2010

Many weekends have passed. I have released what is on svn to foswiki.org as we needed some of the documentation enhancements to easy the pain of installation. And as far as I can tell the SVN code was better than the old even if further fixing is needed for this one.

-- KennethLavrsen - 26 Oct 2010

Yeah, I ran into a problem with this and never finished it.

At the moment, it will restart the master process after a certain number of requests. But this means that for a second or two the wiki will be taken offline, which is no good. So what I wanted to do was respawn the child processes after a number of requests, so there would not be any downtime. But I couldn't find a way to implement this elegantly with CPAN:FCGI.

Going forward, it might be better to use something other than FCGI, but I don't know what alternatives there are. But unfortunately I have no time for Foswiki at my paid work at my moment, so I am unlikely to finish this any time soon.

For new, I will flip back to New, but I don't think this should be closed as this feature is still needed.

-- AndrewJones - 28 Oct 2010

Basically, I am using FastCGIEngineContrib every day and recommend it to everybody. It is easy to set up and has got all the bells and whistles to deal with restart and server load patterns.

I haven't been suffering from memory leaks or at least didn't get aware that there is one. This means that this issue has been dealt with to a certain level that satisfies every-day needs. I am not saying that there aren't any memory leaks left that we can deal with. However the efforts to track down the very least one are a lot higher than the gain you'll get from that.

The rest of it can be dealt with using an intelligent restart technique. FCGID inside apache already has got a lot of options to restart the foswiki backend. In addition we have a request counter inside FastCGIEngineContrib that you can use to limit the amount of requests this one backend is allowed to serve.

Not sure what else we can or should do in this generic catch-all bug report.

Instead, we should close this one and report memory leaks with individual and more targeted bug reports per component.

-- MichaelDaum - 29 Oct 2010