[rt-users] Memory leaks with mod_fastcgi

[Andrew Cobaugh]

On Tue, Aug 20, 2013 at 1:10 PM, Kevin Falcone <falcone at bestpractical.com>wrote:

> On Mon, Aug 19, 2013 at 01:02:35PM -0400, Andrew Cobaugh wrote:
> >    Is there no clean way around memory leaks in RT when using
> mod_fastcgi short of HUPing the
> >    individual rt-server.fcgi processes when they reach a certain size?
> >    Running 4.0.13 right now. With a load balancer in front hitting a
> simple html page located at
> >    /rt/NoAuth/LoadBalancer.html every couple of seconds, we see memory
> usage increase ~100MB per
> >    process with 5 rt-server processes over the course of about 12 hours.
> >    Is there any simple way to track down why memory is increasing so
> much?
>
>
> Is that 100M with no other rt services running but the request for
> Loadbalancer.html or are you mixing testing requests in with
> production RT requests?
>

That was just LoadBalancer.html. No other page hits.


> rt-server.fcgi processes will grow as large as is needed to process
> the current task, so if RT sends a huge email or processes a huge
> attachment, I would expect individual processes to grow.
>
> Your perl build can also affect the size of child processes.
>

We're actually using rpmbuild+shipwright to create packaged,
redistributable RPMs containing everything necessary to run RT.

You can find the package we're using here:
http://yum.ait.psu.edu/ait/rhel/6/base/x86_64/rt413-vessel-opt-4.0.13-1.el6.ait.x86_64.rpm

We are currently using 5.14.1, and here's the output of perl -V,
http://pastebin.com/LC73KMzA

You can try attaching something like
> http://search.cpan.org/~timb/Devel-SizeMe-0.16/
> to a single rt-server.fcgi child and seeing what changes between
> requests.  Simple repeatable actions that cause consistent growth is
> the easiest way to solve something like this.  I'm used to seeing 70M
> stable fcgi processes.
>

I started playing around with Devel::Gladiator a little bit, but started
getting into unfamiliar territory rather quickly. I'll take a look at
Devel::SizeMe.

 --andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20130820/20e55edf/attachment.htm>