[rt-users] FastCGI vs/or FastCGId? System memory "leak"?

Dan Pritts danno at internet2.edu
Mon Jan 16 16:19:48 EST 2006 

I'm far from a fastCGI expert, but my understanding is that you don't
want to run too many fcgi processes - look back through the mailing list
archive for a performance discussion which explains why.  I believe it
had to do with how much caching each process did, independent of the
other.  If i recall the rule of thumb is only as many fcgis as you 
expected simultaneous web hits to the RT server.  based on that in
my small environment i ended up with two.

In my experience it is generally safe to kill the fcgi processes
although i suppose there might be race conditions in them that i'm not aware
of - i run a very small RT installation compared to what i imagine
the size of yours must be, if you're using that much CPU time.

if your environment allows it, you might try running a cron job to kill
the fcgi jobs every night in the middle of the night.

You definitely don't need to restart apache to kill the fcgis.  You may
even be able to kill fcgis individually and new ones will be spawned, which
might reduce the possibility of downtime for you if you have a demanding
environment.


On Fri, Jan 13, 2006 at 01:52:43PM +0100, Tomas Olaj wrote:
> 
> Hi,
> 
> There are many nice advantages to use mod_FastCGI over mod_Perl. Our RT 
> instances has gotten much faster in response time when we switched from 
> mod_Perl to mod_FastCGI.
> 
> As mentioned earlier on this list we are slowly loosing system memory on our
> RT application server, and at some point we need to restart Apache
> (running v2.0.52) when memory and swap has been "eaten away".
> 
> Currently we're using mod_FastCGI v2.4.2 from http://www.fastcgi.com/, but 
> the source code hasn't been maintained since 2003.
> 
> In httpd.conf we have configured:
> FastCgiServer /site/rt-3.4.2/bin/mason_handler.fcgi -idle-timeout 300 
> -processes 10
> 
> (still on 3.4.2, since newer RT versions in 3.4 broke our e-mail 
> administration code modifications, which our *nix users fanaticaly demands 
> as opposed to RT's Mason view.)
> 
> Typically after a long run:
> # ps aux | grep mason
> nobody    8204  0.5  3.1 310572 122160 ?     S     2005 287:57 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8208  0.5  3.1 303116 120788 ?     S     2005 284:10 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8211  0.5  4.3 320840 169716 ?     S     2005 296:36 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8242  0.5  3.2 326480 124112 ?     R     2005 284:07 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8352  0.5  3.4 298260 133776 ?     S     2005 279:41 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8467  0.5  3.6 330692 139136 ?     S     2005 290:36 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8576  0.5  3.0 343052 116868 ?     S     2005 282:37 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8579  0.5  3.9 635708 153624 ?     S     2005 303:06 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8582  0.5  3.2 315260 124844 ?     S     2005 280:31 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> nobody    8585  0.5  3.2 293456 126316 ?     S     2005 284:20 
> /site/perl-5.8.6/bin/perl /site/rt-3.4.2/bin/mason_handler.fcgi
> 
> It's expected that a running Perl process normaly do not free up memory, 
> but e.g. PID 8204 does not time out at all. Is it because it's not idle at 
> all, and too busy working with requests? Should we increase number of 
> processes? They consume a lot of memory, and I think it just increases 
> more and more.
> 
> # top says:
> 
>  13:44:27  up 204 days, 23:12,  2 users,  load average: 0.45, 0.50, 0.65
> 99 processes: 98 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
>            total    0.0%    0.0%    0.2%   0.0%     0.0%    0.0%   99.7%
>            cpu00    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  100.0%
>            cpu01    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  100.0%
>            cpu02    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  100.0%
>            cpu03    0.0%    0.0%    0.9%   0.0%     0.0%    0.0%   99.0%
> Mem:  3857224k av, 3321624k used,  535600k free,       0k shrd,   36708k 
> buff
>                    2736968k actv,  338356k in_d,   15600k in_c
> Swap: 4192944k av, 2149104k used, 2043840k free                 1772712k 
> cached
> 
> ---
> 
> Jesse mentioned at the Amsterdam class that mod_FCGId is another 
> alternative (http://fastcgi.coremail.cn/) to mod_FastCGI, and I will have 
> a closer look at this source. And, the source code looks newer and 
> maintained. ;)
> 
> ---
> 
> Nice little article reference:
> http://www.groovie.org/articles/2004/12/18/fast-cgi-with-html-mason
> 
> ---
> 
> 	Tomi
> 
> -- 
> ________________________________________________________________________
> Tomas A. P. Olaj, email: tomas.olaj at usit.uio.no, web: folk.uio.no/tomaso
>  University of Oslo / USIT (Center for Information Technology Services)
>    System- and Application Management / Applications Management Group
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Be sure to check out the RT Wiki at http://wiki.bestpractical.com
> 
> Download a free sample chapter of RT Essentials from O'Reilly Media at 
> http://rtbook.bestpractical.com
> 
> WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
> San Francisco - Find out more at 
> http://bestpractical.com/services/training.html


danno
--
dan pritts - systems administrator - internet2
734/352-4953 office        734/834-7224 mobile

More information about the rt-users mailing list