If you plan on regularly killing your application (for whatever reason), then this is a pretty good option. This is a pretty common practice for apache modules and fastcgi applications as a hold-over from dealing with older leaky C apps.<br>
<br>I'd personally prefer for my Ruby web apps to re-run the GC rather than have to startup/shutdown/parse configs/connect to external resources costs, but it's because they are far less likely to leak memory that the GC can't catch or get into an unstable state.<br>
<br>- scott<br><br><div class="gmail_quote">On Fri, Mar 21, 2008 at 1:22 PM, Evan Weaver <<a href="mailto:evan@cloudbur.st">evan@cloudbur.st</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> The alternative is to terminate your application after N number of requests and never run the > GC, which I'm not a fan of.<br>
<br>
</div>WSGI (Python) can do that, and it's a pretty nice alternative to<br>
having Monit kill a leaky app that may have a bunch of requests queued<br>
up (Mongrel soft shutdown not withstanding).<br>
<br>
Evan<br>
<div><div></div><div class="Wj3C7c"><br>
On Fri, Mar 21, 2008 at 3:23 PM, Scott Windsor <<a href="mailto:swindsor@gmail.com">swindsor@gmail.com</a>> wrote:<br>
> On Fri, Mar 21, 2008 at 11:49 AM, Kirk Haines <<a href="mailto:wyhaines@gmail.com">wyhaines@gmail.com</a>> wrote:<br>
><br>
> ><br>
> > On Fri, Mar 21, 2008 at 12:12 PM, Scott Windsor <<a href="mailto:swindsor@gmail.com">swindsor@gmail.com</a>><br>
> wrote:<br>
> > > Sorry, for the re-post, but I'm new to the mailing list and wanted to<br>
> bring<br>
> > > back up and old topic I saw in the archives.<br>
> > ><br>
> > > <a href="http://rubyforge.org/pipermail/mongrel-users/2008-February/004991.html" target="_blank">http://rubyforge.org/pipermail/mongrel-users/2008-February/004991.html</a><br>
> > ><br>
> > > I think a patch to delay garbage collection and run it later is pretty<br>
> > > important for high performance web applications. I do understand the<br>
> ><br>
> > In the vast majority of cases you are going to do a worse job of<br>
> > determining when and how often to run the GC than even MRI Ruby's<br>
> > simple algorithms. MRI garbage collection stops the world -- nothing<br>
> > else happens while the GC runs -- so when talking about overall<br>
> > throughput on an application, you don't want it to run any more than<br>
> > necessary.<br>
> ><br>
> > I don't use Rails, but in the past I have experimented with this quite<br>
> > a lot under IOWA, and in my normal applications (i.e. not using<br>
> > RMagick) I could never come up with an algorithm of self-managed<br>
> > GC.disable/GC.enable/GC.start that gave the same overall level of<br>
> > throughput that I got by letting Ruby start the GC according to its<br>
> > own algorithms. That experience makes me skeptical of that approach<br>
> > in the general case, though there are occasional specific cases where<br>
> > it can be useful.<br>
> ><br>
> ><br>
> > Kirk Haines<br>
><br>
> I understand that the GC is quite knowledgeable about when to run garbage<br>
> collection when examining the heap. But, the GC doesn't know anything about<br>
> my application or it's state. The fact that when the GC runs everything<br>
> stops is why I'd prefer to limit when the GC will run. I'd rather it run<br>
> outside of serving a web request rather then when it's right in the middle<br>
> of serving requests.<br>
><br>
> I know that the ideal situation is to not need to run the GC, but the<br>
> reality is that I'm using various gems and plugins and not all are well<br>
> behaved and free of memory leaks. Rails itself may also have regular leaks<br>
> from time to time and I'd prefer to have my application consistently be slow<br>
> than randomly (and unexpectedly) be slow. The alternative is to terminate<br>
> your application after N number of requests and never run the GC, which I'm<br>
> not a fan of.<br>
><br>
> - scott<br>
><br>
</div></div><div class="Ih2E3d">> _______________________________________________<br>
> Mongrel-users mailing list<br>
> <a href="mailto:Mongrel-users@rubyforge.org">Mongrel-users@rubyforge.org</a><br>
> <a href="http://rubyforge.org/mailman/listinfo/mongrel-users" target="_blank">http://rubyforge.org/mailman/listinfo/mongrel-users</a><br>
><br>
<br>
<br>
<br>
</div><font color="#888888">--<br>
Evan Weaver<br>
Cloudburst, LLC<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Mongrel-users mailing list<br>
<a href="mailto:Mongrel-users@rubyforge.org">Mongrel-users@rubyforge.org</a><br>
<a href="http://rubyforge.org/mailman/listinfo/mongrel-users" target="_blank">http://rubyforge.org/mailman/listinfo/mongrel-users</a><br>
</div></div></blockquote></div><br>