From borko.boyanov at gmail.com  Thu Mar  1 00:06:36 2007
From: borko.boyanov at gmail.com (Boril Boyanov)
Date: Thu, 1 Mar 2007 07:06:36 +0200
Subject: [Mongrel] "mongrel-users@rubyforge.org": E-Mail usage:
Message-ID: <90cae7cc0702282106r7553ed44kdaf391547ff1b94a@mail.gmail.com>

Dear Mongrel users,
Usage of the E-Mail is for some PRIVATE communication.
There are other accesses in class definitions:

class Users
{
private:
  my_gal, my_best_buddy, me
protected:
 my_homies
public:
evey dude in the world (can get... what? eliminatted puhleeeeze, riiiiite,
think damnit)
}

...aaaaand some very secure phorums and forums could be used... right?
riiiite :)

So... i suggest using that, and remember, Please Update Mongrel and keep it
ON TOP!
Other suggestions:
We are very pleased we can use Ruby lang now :) :) *kisses* to the Lang!
We are very pleased we can use Ruby Jewel  now :) :) kisses to all

we are very plesaed to announce that soon the work on BHDZ->variant:
Diamandos will start.
YOU checked the access to it? no? ok. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070301/461dcd78/attachment.html 

From chris at codeintensity.com  Thu Mar  1 00:45:20 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Wed, 28 Feb 2007 21:45:20 -0800
Subject: [Mongrel] Mongrel performing only half as fast as Apache?
In-Reply-To: <20070228090539.cc7f79b5.zedshaw@zedshaw.com>
References: <8c8513100702271540p303946caq2f3b344f47c0c305@mail.gmail.com>
	<f4cd26df0702271742m444937f4yc0efb7b56a86a3b8@mail.gmail.com>
	<8c8513100702271939h78212753r59633489098b69e1@mail.gmail.com>
	<8c8513100702272202m3969b2f5je6c1070ae23adbba@mail.gmail.com>
	<20070228090539.cc7f79b5.zedshaw@zedshaw.com>
Message-ID: <8c8513100702282145s2603ecd8le946c1f23e9cb7ae@mail.gmail.com>

Ok, thanks.  Yes, it seems that basically things are somewhat as expected.
It's definitely a good exercise in knowing how noticeably certain things
(like sessions, etc.) affect the performance.  At this point I've removed
Apache from the mix, as we wouldn't be using it anyway (we use it in dev as
it's what we have now that allows us to easily run static, and multiple
Rails on a single box and balance across that, etc.  But, I will probably
look at Nginx as an alternative.  For my tests I've now switched to Pen as
that seems the least obtrusive, and is about as simple as we could get
before having no software load balance/closes to hardware LB.

On 2/28/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> On Tue, 27 Feb 2007 22:02:58 -0800
> "Christopher Bailey" <chris at codeintensity.com> wrote:
>
> > Moving forward, I may not understand httperf's num-conns, and rate, as
> > applied to scaling up the number of Mongrels.  Either that, or my server
> has
> > issues.
> >
> > httperf --hog --server lab05 --port 80 --uri /mongrel_alive.html
> --num-conns
> > 4500 --rate 450
> >
> > This gives me back 10 seconds of time, and 450 req/sec, 450 conn/sec.
>
> Try inching that up incrementally until you find the "sweet spot".
> It's probably going to be 450 or near it, but try 500.  You'll know you
> passed the sweet spot when the req/sec crashes suddenly.  I do kind of
> a binary search algo until I find the right number.
>
> > So, now I add a Mongrel into the mix, restart Apache, etc.  I would
> think
> > that I can now use:
> >
> > httperf --hog --server lab05 --port 80 --uri /mongrel_alive.html
> --num-conns
> > 9000 --rate 900
>
> You won't get 900 right away, especially since you have one CPU and are
> maxing them out but if you get 350 req/sec then try again inching it
> down until you get a steady number.  Try 800 to see if that gives you
> 800 req/sec, then further down until you get it, then inch up to see
> where the sweet spot is.
>
> > In my case it starts breaking down with just two Mongrels (and to be
> clear,
> > I was not running top during the tests).  I drop to about 350 req/sec
> > without errors.
>
> Yep, and that's just kind of the way it goes.  In your case, having
> more mongrels isn't going to get you higher performance, so just add
> one more mongrel and use your mongrel processes more to ensure
> concurrency when running Rails.  Also, you haven't even hit testing
> your rails performance yet, do that too and just kind of accept it as
> your speed then plan for it.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070228/5535dcac/attachment.html 

From john at swiftshire.org  Thu Mar  1 13:05:00 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 13:05:00 -0500
Subject: [Mongrel] mongrel_cluster
Message-ID: <45E715CC.9090005@swiftshire.org>

Hello,

Apologize if this is a annoying faq but folks here are trying to get a 
cluster going and something odd is happening. When 'mongrel_rails 
cluster::start' is run, the following error is getting returned:

ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in 
category /commands


Is this the result of a simple path issue or perhaps a broken mongrel 
install? Curious if anyone has seen this before or has any idea what 
might be the cause.

TIA,
js

From atmos at atmos.org  Thu Mar  1 13:49:51 2007
From: atmos at atmos.org (Corey Donohoe)
Date: Thu, 1 Mar 2007 12:49:51 -0600
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>

sudo gem install mongrel_cluster --source
http://mongrel.rubyforge.org/releases/

On 3/1/07, John Swift <john at swiftshire.org> wrote:
>
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a
> cluster going and something odd is happening. When 'mongrel_rails
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel
> install? Curious if anyone has seen this before or has any idea what
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070301/61bd756b/attachment.html 

From pberry at gmail.com  Thu Mar  1 14:17:56 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 1 Mar 2007 11:17:56 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>

Do you have multiple gem for mongrel_cluster installed?  I ran into
this and uninstalling the old gems worked for me.

Pat

On 3/1/07, John Swift <john at swiftshire.org> wrote:
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a
> cluster going and something odd is happening. When 'mongrel_rails
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel
> install? Curious if anyone has seen this before or has any idea what
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From matte at ruckuswireless.com  Thu Mar  1 14:47:14 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Thu, 01 Mar 2007 11:47:14 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E715CC.9090005@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
Message-ID: <45E72DC2.3030104@ruckuswireless.com>

I'll +1 for what Patrick Berry said.  do a "gem cleanup mongrel_cluster" 
(sudo if you need to) and that should fix it.  I had the same problem 
and that fixed it.

matte

John Swift wrote:
> Hello,
>
> Apologize if this is a annoying faq but folks here are trying to get a 
> cluster going and something odd is happening. When 'mongrel_rails 
> cluster::start' is run, the following error is getting returned:
>
> ERROR RUNNING 'cluster::start': Plugin /cluster::start does not exist in 
> category /commands
>
>
> Is this the result of a simple path issue or perhaps a broken mongrel 
> install? Curious if anyone has seen this before or has any idea what 
> might be the cause.
>
> TIA,
> js
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   



From john at swiftshire.org  Thu Mar  1 15:42:56 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 15:42:56 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
Message-ID: <45E73AD0.7060202@swiftshire.org>

Patrick Berry wrote:
> Do you have multiple gem for mongrel_cluster installed?  I ran into
> this and uninstalling the old gems worked for me.
> 
> Pat
> 

Thanks Pat (and Corey). The install was done completely from scratch 
with just the following:

   gem install mongrel_cluster -y


Starting over and trying Corey's suggestion now.

js

From lawver at gmail.com  Thu Mar  1 15:42:33 2007
From: lawver at gmail.com (Kevin Lawver)
Date: Thu, 01 Mar 2007 15:42:33 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
Message-ID: <45E73AB9.5080006@gmail.com>

This worked like a charm, thanks everybody!  (yes, I'm the guy John was 
talking about)

Cheers,
Kevin Lawver

Corey Donohoe wrote:
> sudo gem install mongrel_cluster --source 
> http://mongrel.rubyforge.org/releases/
> 



From john at swiftshire.org  Thu Mar  1 15:45:02 2007
From: john at swiftshire.org (John Swift)
Date: Thu, 01 Mar 2007 15:45:02 -0500
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
References: <45E715CC.9090005@swiftshire.org>
	<c75e5f320703011049td8af080y1b30110a3b85c265@mail.gmail.com>
Message-ID: <45E73B4E.1010407@swiftshire.org>

Corey Donohoe wrote:
> sudo gem install mongrel_cluster --source 
> http://mongrel.rubyforge.org/releases/
>

Yep, that did it. Things are copacetic. Thanks very much.

js

From pberry at gmail.com  Thu Mar  1 18:44:00 2007
From: pberry at gmail.com (Patrick Berry)
Date: Thu, 1 Mar 2007 15:44:00 -0800
Subject: [Mongrel] mongrel_cluster
In-Reply-To: <45E73AD0.7060202@swiftshire.org>
References: <45E715CC.9090005@swiftshire.org>
	<ef13ff170703011117w472ddb0ds92e8166d3acfcdec@mail.gmail.com>
	<45E73AD0.7060202@swiftshire.org>
Message-ID: <ef13ff170703011544g28d29bcdr1712fc9d526d9c8e@mail.gmail.com>

On 3/1/07, John Swift <john at swiftshire.org> wrote:
> Patrick Berry wrote:
> > Do you have multiple gem for mongrel_cluster installed?  I ran into
> > this and uninstalling the old gems worked for me.
> >
> > Pat
> >
>
> Thanks Pat (and Corey). The install was done completely from scratch
> with just the following:
>
>    gem install mongrel_cluster -y
>
>
> Starting over and trying Corey's suggestion now.
>

It should be noted that this will install a "pre-release" version of
mongrel_cluster.  That being said, we're running it in production
right now (what better test could you ask for, right?).  We also have
the luxury of having very small audiences.

Pat

From tomawng at yahoo.fr  Thu Mar  1 18:45:15 2007
From: tomawng at yahoo.fr (tom wang)
Date: Fri, 2 Mar 2007 00:45:15 +0100 (CET)
Subject: [Mongrel] RE : Re:  Deployement options
In-Reply-To: <14adac440702281958p2752125bpb75c0adf64790024@mail.gmail.com>
Message-ID: <749645.56945.qm@web23413.mail.ird.yahoo.com>

Thanks a lot everybody for the answer,  I'm going to
use nginx together with a pack of mongrels....
I hadn't thought there was so much difference between
the different web framework on ruby (ie. why isn't
rails threadsafe? ) but since I'm going to go with
rails, I'll have to have more mongrels process if I
understand correctly....


A bit offtopic, what do you people think of grids like
applogic (http://www.3tera.com/applogic.html,
http://www.thegridlayer.com/index.php), is it a good
solution to scale the system has more and more
requests are being made? Has anybody ever tried using
it?

Another question I had is what do you think of using
gentoo for the server, I have a lot of experience in
using it as my primary desktop operating system
(before I switched to mac) but I wonder if it's a good
idea on a server.... The tendency to have problems
when a gentoo installation had not been updated for a
long time and you suddenly update worries me.


Again, thanks 
and thanks Zed for developing mongrel


--- Craig Kuhns <craigkuhns at gmail.com> a ?crit?:

> I would definitely check out using nginx.  I have
> set it up a number
> of times for production sites using rails and nginx
> and mongrel and it
> has performed incredibly well.  If you want a good
> walkthrough
> installing and configuring it with rails and several
> mongrels check
> out Kyle Kochis's blog - kyledev.blogspot.com.
> 
> Craig Kuhns
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 



	

	
		
___________________________________________________________________________ 
D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! 
Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses 
http://fr.answers.yahoo.com

From alexey.verkhovsky at gmail.com  Fri Mar  2 15:49:22 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 2 Mar 2007 14:49:22 -0600
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
Message-ID: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>

Dear all,

I am researching solutions for "how do you squeeze as many Rails apps as you
can on a cluster" problem.

Environment constraints are as follows:

* 4 commodity web servers (2 CPUs, 8 Gb of RAM each)
* shared file storage and database (big, fast, not a bottleneck)
* multiple Rails apps running on it
* normally, the load is insignificant, but from time to time any of these
apps can have a big, unpredictable spike in load, that takes (say) 8
Mongrels to handle.

The bottleneck, apparently, is RAM. At 100 Mb per Mongrel process, you can
only put 320 Mongrel processes on those boxes, and under specified
parameters you can only handle 40 apps on the hardware described above. PHP
can handle thousands of sites under the same set of constraints.

We could use lighty + FastCGI combo, but it has a bad reputation. I wonder
if it's because of bugs in implementation, or it's just not designed for
these scenarios (if not, what's the limitation, and can it be fixed?)

If anybody knows a ready-made solution to this problem, please let me know.
The last thing I want to do is reinvent the wheel.

If anybody knows a load balancer smart enough to start and kill multiple
processes across the entire cluster, based on demand per application, please
let me know about that, too.

Finally, I've been thinking about making Rails execution within Mongrel
concurrent by spawning multiple Rails processes as children of Mongrel, and
talking to them through local pipes (just like FastCGI does, but a
Ruby-specific solution). This may allow a single Mongrel to scale 3-4 times
better than now, and also to scale down if no requests are coming in the
last, say, 10 minutes. A "blank" Ruby process only takes 7Mb of RAM, perhaps
a "blank" Mongrel is not much more (haven't checked yet). Wonder if this
makes sense, or am I just crazy.

I think, we can implement (and open-source) any solution that needs weeks
rather than years of effort.

Thoughts?

Best regards,
Alex Verkhovsky
ThoughtWorks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070302/fbe5d764/attachment.html 

From jamie at dangosaur.us  Sun Mar  4 00:18:46 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 00:18:46 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
Message-ID: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>

I'm running the latest mongrel (1.0.1) and the latest mongrel_cluster  
(1.0.1.1) on FreeBSD 6.1.

When I use capistrano to try to stop or restart my cluster I get this  
(partial) output:

ps: Process environment requires procfs(5)

And my Mongrel processes haven't stopped.

Any ideas?

Thanks,

Jamie

From jw at innerewut.de  Sun Mar  4 04:17:22 2007
From: jw at innerewut.de (Jonathan Weiss)
Date: Sun, 04 Mar 2007 10:17:22 +0100
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
Message-ID: <45EA8EA2.9010307@innerewut.de>

Jamie Orchard-Hays wrote:
> I'm running the latest mongrel (1.0.1) and the latest mongrel_cluster  
> (1.0.1.1) on FreeBSD 6.1.
> 
> When I use capistrano to try to stop or restart my cluster I get this  
> (partial) output:
> 
> ps: Process environment requires procfs(5)
> 
> And my Mongrel processes haven't stopped.
> 
> Any ideas?

The message means that you need the procfs virtual filesystem mounted. 
Normally you do not need this under FreeBSD.

I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2 without any 
glitches, so maybe mongrel_cluster 1.0.1.1 introduces some 
Linux-specific ps syntax that requires procfs.

I will try to upgrade my mongrel_cluster version and see if I get the 
same message.

> 
> Thanks,
> 
> Jamie

Jonathan

-- 
Jonathan Weiss
http://blog.innerewut.de

From wyhaines at gmail.com  Sun Mar  4 10:12:59 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sun, 4 Mar 2007 08:12:59 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
Message-ID: <f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>

On 3/2/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> Dear all,
>
> I am researching solutions for "how do you squeeze as many Rails apps as you
> can on a cluster" problem.
>
> Environment constraints are as follows:
>
> * 4 commodity web servers (2 CPUs, 8 Gb of RAM each)
> * shared file storage and database (big, fast, not a bottleneck)
> * multiple Rails apps running on it
> * normally, the load is insignificant, but from time to time any of these
> apps can have a big, unpredictable spike in load, that takes (say) 8
> Mongrels to handle.
>
> The bottleneck, apparently, is RAM. At 100 Mb per Mongrel process, you can
> only put 320 Mongrel processes on those boxes, and under specified
> parameters you can only handle 40 apps on the hardware described above. PHP
> can handle thousands of sites under the same set of constraints.

Do you have a sense for how many requests/second capacity represents a
rate that can survive slashdotting?  i.e. you are assuming 8
mongrels/app.  So what capacity do those 8 mongrels represent?

> If anybody knows a load balancer smart enough to start and kill multiple
> processes across the entire cluster, based on demand per application, please
> let me know about that, too.

I have developed a clustering proxy from scratch (the first fledgling
release of it should be today) that is in a good position for feature
requests.  Having a single load balancer starting and stopping
processes across a cluster, though, calls for quite a bit of
complexity.  A compromise, that would just manage backends on the same
machine that the proxy is running on, could have potential.  Something
would proxy requests out to nodes, and the local proxy on each node
would manage it's pack of backend processes.  The friction of having
two layers of proxying might create too much throughput entropy,
through.

> Finally, I've been thinking about making Rails execution within Mongrel
> concurrent by spawning multiple Rails processes as children of Mongrel, and
> talking to them through local pipes (just like FastCGI does, but a
> Ruby-specific solution). This may allow a single Mongrel to scale 3-4 times
> better than now, and also to scale down if no requests are coming in the
> last, say, 10 minutes. A "blank" Ruby process only takes 7Mb of RAM, perhaps
> a "blank" Mongrel is not much more (haven't checked yet). Wonder if this
> makes sense, or am I just crazy.

This sounds like a way to implement something similar to what I described above.


Kirk Haines

From jamie at dangosaur.us  Sun Mar  4 10:44:25 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 10:44:25 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <45EA8EA2.9010307@innerewut.de>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
Message-ID: <79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>

Thanks. I'd found a bit about that after I sent the message. Things  
worked fine with 0.2.1--except that mongrel_cluster's restart did not  
work properly if nothing was running, which cost me an hour a day  
earlier before I realized what was wrong. That's was my motivation to  
upgrade.

If you have any simple instructions about how to get this working on  
FreeBSD, I'll be very grateful!

Jamie

On Mar 4, 2007, at 4:17 AM, Jonathan Weiss wrote:

> The message means that you need the procfs virtual filesystem mounted.
> Normally you do not need this under FreeBSD.
>
> I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2  
> without any
> glitches, so maybe mongrel_cluster 1.0.1.1 introduces some
> Linux-specific ps syntax that requires procfs.
>
> I will try to upgrade my mongrel_cluster version and see if I get the
> same message.


From jamie at dangosaur.us  Sun Mar  4 11:17:32 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 11:17:32 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
Message-ID: <4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>

Kirk, I followed the instructions on the following link, but no love.  
I seem to have mounted fine, but I'm getting the same error reported  
back from mongrel_cluster_ctl.

http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2

Jamie

On Mar 4, 2007, at 10:44 AM, Jamie Orchard-Hays wrote:

> Thanks. I'd found a bit about that after I sent the message. Things
> worked fine with 0.2.1--except that mongrel_cluster's restart did not
> work properly if nothing was running, which cost me an hour a day
> earlier before I realized what was wrong. That's was my motivation to
> upgrade.
>
> If you have any simple instructions about how to get this working on
> FreeBSD, I'll be very grateful!
>
> Jamie
>
> On Mar 4, 2007, at 4:17 AM, Jonathan Weiss wrote:
>
>> The message means that you need the procfs virtual filesystem  
>> mounted.
>> Normally you do not need this under FreeBSD.
>>
>> I use Mongrel 1.0.1 + mongrel_cluster (0.2.1) on FreeBSD 6.2
>> without any
>> glitches, so maybe mongrel_cluster 1.0.1.1 introduces some
>> Linux-specific ps syntax that requires procfs.
>>
>> I will try to upgrade my mongrel_cluster version and see if I get the
>> same message.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pberry at gmail.com  Sun Mar  4 11:36:28 2007
From: pberry at gmail.com (Patrick Berry)
Date: Sun, 4 Mar 2007 08:36:28 -0800
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
Message-ID: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>

On 3/4/07, Jamie Orchard-Hays <jamie at dangosaur.us> wrote:
> Kirk, I followed the instructions on the following link, but no love.
> I seem to have mounted fine, but I'm getting the same error reported
> back from mongrel_cluster_ctl.
>
> http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2
>
> Jamie
>

It is a ps command problem.  I ran into the same issue when testing
locally on OS X.  Options are to wait for another *pre-release* of
mongrel_cluster or making the following mod to line 164 of init.rb in
the check_process method:

old:   ps_output = `ps -o args= -p #{pid}`
new: ps_output = `ps -o command= -p #{pid}`

Pat

From jamie at dangosaur.us  Sun Mar  4 12:47:38 2007
From: jamie at dangosaur.us (Jamie Orchard-Hays)
Date: Sun, 4 Mar 2007 12:47:38 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>
	<45EA8EA2.9010307@innerewut.de>
	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>
	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
	<ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
Message-ID: <0D15D6D1-98E9-4A2C-8FAC-529639A8575C@dangosaur.us>

Patrick, I assume you mean the gem file on the remote server. This  
didn't change the error I get, or cause restart to work.

Thanks,
Jamie

On Mar 4, 2007, at 11:36 AM, Patrick Berry wrote:

> It is a ps command problem.  I ran into the same issue when testing
> locally on OS X.  Options are to wait for another *pre-release* of
> mongrel_cluster or making the following mod to line 164 of init.rb in
> the check_process method:
>
> old:   ps_output = `ps -o args= -p #{pid}`
> new: ps_output = `ps -o command= -p #{pid}`
>
> Pat


From bradley at railsmachine.com  Sun Mar  4 13:19:55 2007
From: bradley at railsmachine.com (Bradley Taylor)
Date: Sun, 04 Mar 2007 13:19:55 -0500
Subject: [Mongrel] FreeBSD 6.1 mongrel_cluster and procfs message
In-Reply-To: <ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
References: <8903232B-3D1D-4D79-B02D-B6995E7F96D1@dangosaur.us>	<45EA8EA2.9010307@innerewut.de>	<79E851EE-C1BB-485B-BFE9-B8660683F2DE@dangosaur.us>	<4C44E99C-CB5D-4543-A1D3-C87E5139B295@dangosaur.us>
	<ef13ff170703040836ie98503as8f08ec01f4dce28a@mail.gmail.com>
Message-ID: <45EB0DCB.5050902@railsmachine.com>

This 'ps' syntax is really annoying. If my score-keeping is correct:

Linux and FreeBSD seem to support both 'args' and 'command'.
Darwin/MacOSX doesn't support 'args'.
Solaris doesn't support 'command'.

I guess I need to resort to platform checks. I was hoping to avoid this 
by using the 'standard format specifiers'. The great thing about 
standards is that there are so many to choose from.

Bradley

Patrick Berry wrote:
> On 3/4/07, Jamie Orchard-Hays <jamie at dangosaur.us> wrote:
>> Kirk, I followed the instructions on the following link, but no love.
>> I seem to have mounted fine, but I'm getting the same error reported
>> back from mongrel_cluster_ctl.
>>
>> http://os.newsforge.com/os/06/03/22/1531252.shtml?tid=8&tid=2
>>
>> Jamie
>>
> 
> It is a ps command problem.  I ran into the same issue when testing
> locally on OS X.  Options are to wait for another *pre-release* of
> mongrel_cluster or making the following mod to line 164 of init.rb in
> the check_process method:
> 
> old:   ps_output = `ps -o args= -p #{pid}`
> new: ps_output = `ps -o command= -p #{pid}`
> 
> Pat
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From alexey.verkhovsky at gmail.com  Sun Mar  4 14:36:31 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Sun, 4 Mar 2007 13:36:31 -0600
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<f4cd26df0703040712w311ffc94hc894fccf04dcd513@mail.gmail.com>
Message-ID: <3945c4270703041136l39fd677aree0424ff84382b92@mail.gmail.com>

On 3/4/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> Do you have a sense for how many requests/second capacity represents a
> rate that can survive slashdotting?


"Survive slashdotting" is just a phrase. The target is ~100 requests/sec for
dynamic page rendering,

I have developed a clustering proxy from scratch (the first fledgling
> release of it should be today) that is in a good position for feature
> requests.

If it's free, open source, and done well, I am in a good position to give
you those feature requests. Even lend a hand in implementing them, probably.
Let's continue this conversation off the list.

Having a single load balancer starting and stopping
> processes across a cluster, though, calls for quite a bit of
> complexity.

Yeah. Hopefully, it will prove unnecessary.

A compromise, that would just manage backends on the same
> machine that the proxy is running on, could have potential.


Litespeed and mod_fcgid both do this fairly well. But proxy to Mongrels
seems wiser, because Mongrel is a de-facto standard development environment.
Little extra CPU time for avoiding deployment pains is always a good deal.

Best regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070304/527bc894/attachment.html 

From dee.zsombor at gmail.com  Mon Mar  5 02:10:09 2007
From: dee.zsombor at gmail.com (Dee Zsombor)
Date: Mon, 05 Mar 2007 09:10:09 +0200
Subject: [Mongrel] Multiple apps on the same server,
 all should be able to survive slashdotting
In-Reply-To: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
Message-ID: <45EBC251.2060807@gmail.com>

Alexey Verkhovsky wrote:
> We could use lighty + FastCGI combo, but it has a bad reputation. I 
> wonder if it's because of bugs in implementation, or it's just not 
> designed for these scenarios (if not, what's the limitation, and can it 
> be fixed?)

My personal experience points to the contrary, using FCGI listeners (if 
you have the option of dumping apache for lighttpd) works well. Just spawn 
the fcgi listeners externally from script/process/spinner, then tell only 
the ports to lighty where fcgi listeners run:

>  fastcgi.server              = ( ".fcgi" =>
>                                   ( "localhost-7000" => ( "host" => "127.0.0.1", "port" => 7001 ) ),
>                                   ( "localhost-7001" => ( "host" => "127.0.0.1", "port" => 7002 ) ),
>                                   ( "localhost-7002" => ( "host" => "127.0.0.1", "port" => 7003 ) )
>                                 )

Apache with fcgi is a pain true, but not with lighttpd.

Zsombor
-- 
Company  - http://primalgrasp.com
Thoughts - http://deezsombor.blogspot.com

From brianpdoyle at gmail.com  Mon Mar  5 15:30:30 2007
From: brianpdoyle at gmail.com (Brian Doyle)
Date: Mon, 5 Mar 2007 13:30:30 -0700
Subject: [Mongrel] mongrel goes out to lunch for about 5 - 10 minutes
Message-ID: <a2c7a60e0703051230q4be25e79n86b6f61b36568ff5@mail.gmail.com>

Not sure if this is the list for posting questions like this but please let
me know.  We are using Mongrel 0.13.4, Mongrel Cluster 0.2.1  with Rails
1.2.2 with 3 different mongrel processes running in the cluster.  All
appears to be well for hours and then one of the mongrel processes appears
to hang and all incoming requests to that process timeout.  The requests are
not logged in the rails log, (production.log) and we do not see anything in
the mongrel.log so it is making it a bit hard to debug.  I know we can do
more debug logging for mongrel but we were attempting to wait to do that
until further investigation.

Eventually that mongrel process will "come back to life" and continue
serving requests again like nothing ever happened.  Nothing in any logs to
indicate the problem.  When I say eventually it appears anywhere from 5 to
10 minutes of time.  We are in the process of doing more debugging like
monitoring the network, database, etc. but just wondering if there is
something else we should be on the lookout for.   It appears that all
previous requests to that mongrel process are successful with no errors.
We are monitoring the 3 mongrel processes using Big Brother hitting the same
page.  This page doesn't require hits to the db, mail servers or memcache
(all services we use for other parts of the website.)  Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070305/455d9d3a/attachment.html 

From jaywhy at gmail.com  Mon Mar  5 17:10:06 2007
From: jaywhy at gmail.com (Jason Yates)
Date: Mon, 5 Mar 2007 17:10:06 -0500
Subject: [Mongrel] cluster with environment variables
In-Reply-To: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
References: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
Message-ID: <4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>

I should have responded earlier to myself.  Just in case others have
similar problems in the future.

The problem wasn't mongrel at all.  However, the issue seemed to be
coming from mongrel, because for whatever reason an error from Rjb
wasn't getting logged

The problem was Java was eating up all the available memory.  Because
each mongrel instance would start its own Java process. The first one
would steal all the available memory. Then the second couldn't even
start because no memory was available.  Hence one mongrel instance
would work the other wouldn't

The JRE does this because it checks for available system memory and
allocates a portion of it.  Which is fine, however in my case I'm
using a virtual server.  So I only had a 256mb portion of the 4gbs
Java thought it had to play with.

Anyways I blogged about it.  If anyone cares.

http://jaywhy.wordpress.com/2007/03/05/pdf-templates-via-rails/

On 2/23/07, Jason Yates <jaywhy at gmail.com> wrote:
> In production I've setup a mongrel cluster of 2 servers.  Now I'm
> using RJB(ruby java bridge).  So I need certain java environment
> variables set before mongrel starts.
>
> So I set them:
>
> export LD_LIBRARY_PATH=/usr/java/jdk1.6.0/jre/lib/i386/:/usr/java/jdk1.6.0/jre/lib/i386/client/:./
> export JAVA_HOME=/usr/java/jdk1.6.0/
>
> Then I run "mongrel_rails cluster::start".
>
> Now for whatever reason only the first server in the cluster seems
> have the environment variables set.  Like as if the environment is
> getting blanked out after the first server starts but before the
> second.
>
> So I on the page using RJB.  I end up with this weird refresh problem.
>  Where it works, then errors, works, error, etc.
>
> I'm using rails 1.2.1 and mongrel 1.0.1 and cluster 0.2.1.  If that helps.
>
> --
> Jason Yates
> jaywhy at gmail.com
>


-- 
Jason Yates
jaywhy at gmail.com

From luislavena at gmail.com  Mon Mar  5 17:41:28 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 5 Mar 2007 19:41:28 -0300
Subject: [Mongrel] cluster with environment variables
In-Reply-To: <4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>
References: <4cbfccd70702231233g5b4defdy80981ae109c7d0d5@mail.gmail.com>
	<4cbfccd70703051410n61e2332dm8ff551a6743dca2b@mail.gmail.com>
Message-ID: <71166b3b0703051441u798537c6l37c9ff6bd6b1ab12@mail.gmail.com>

On 3/5/07, Jason Yates <jaywhy at gmail.com> wrote:
> I should have responded earlier to myself.  Just in case others have
> similar problems in the future.
>
> The problem wasn't mongrel at all.  However, the issue seemed to be
> coming from mongrel, because for whatever reason an error from Rjb
> wasn't getting logged
>
> The problem was Java was eating up all the available memory.  Because
> each mongrel instance would start its own Java process. The first one
> would steal all the available memory. Then the second couldn't even
> start because no memory was available.  Hence one mongrel instance
> would work the other wouldn't
>

You should have used BackgrounDrb and some queue/method to communicate
with your mongrel_cluster instead, that way, only one java process
will be running.

> The JRE does this because it checks for available system memory and
> allocates a portion of it.  Which is fine, however in my case I'm
> using a virtual server.  So I only had a 256mb portion of the 4gbs
> Java thought it had to play with.
>
> Anyways I blogged about it.  If anyone cares.
>
> http://jaywhy.wordpress.com/2007/03/05/pdf-templates-via-rails/
>

Still long-running process or process that eat a lot of resources from
your web application is wise, injecting them into the whole web
serving experience is a pain to debug.

Good to knwo you solved this.

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From 2828628 at gmail.com  Tue Mar  6 00:11:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 13:11:17 +0800
Subject: [Mongrel] Memory leaks in my site
Message-ID: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>

Hi all,

My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now, i
have a problem on memory leaks with mongrel. My site is running 5 mongrel
processes on a 2G RAM machine, the memory of each process grows from about
20M to about 250M, but it never recover to the initial 20M, so i had to
restart the mongrel processes once per day. The load is about 1M hits per
day.

Waiting for your help, thanks.

Ken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/584bf2c7/attachment-0001.html 

From luislavena at gmail.com  Tue Mar  6 00:45:07 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 6 Mar 2007 02:45:07 -0300
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
Message-ID: <71166b3b0703052145l7c08731s23b4a66a8d51cd9a@mail.gmail.com>

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> Hi all,
>
> My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now, i
> have a problem on memory leaks with mongrel. My site is running 5 mongrel
> processes on a 2G RAM machine, the memory of each process grows from about
> 20M to about 250M, but it never recover to the initial 20M, so i had to
> restart the mongrel processes once per day. The load is about 1M hits per
> day.
>

Hello Ken,

A few things you share about your site are:

1) Using RMagick? or perform any other image manupulation/thumbnailing?
2) have fastthread gem installed?
3) perform file uploads thru rails? Or use send_file or file sending
of dynamic files from rails.

With that information other users on the list could share their
experiences, since every application uses different gem, libraries or
utilities, and offer a generic answer without deeper knowledge of the
problem is impossible.

Regards,

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From jeremy at bitsweat.net  Tue Mar  6 00:53:30 2007
From: jeremy at bitsweat.net (Jeremy Kemper)
Date: Mon, 5 Mar 2007 21:53:30 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
Message-ID: <69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>

On 3/5/07, Ken Wei <2828628 at gmail.com> wrote:
>
> My environment is ruby-1.8.4, rails 1.2.2, mongrel 1.0.1, linux 2.6. Now,
> i have a problem on memory leaks with mongrel. My site is running 5 mongrel
> processes on a 2G RAM machine, the memory of each process grows from about
> 20M to about 250M, but it never recover to the initial 20M, so i had to
> restart the mongrel processes once per day. The load is about 1M hits per
> day.


Are you running in production or development mode?

jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070305/4742b397/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:23:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:23:17 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
Message-ID: <2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>

Hi,

First of all thanks everyone for their responses.

> 1) Using RMagick? or perform any other image manupulation/thumbnailing?
nope

> 2) have fastthread gem installed?
yes, installed fastthread (0.6.4.1)

> 3) perform file uploads thru rails? Or use send_file or file sending of
dynamic files from rails.
nope

and, i'm running on production mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/b33dc2ed/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:26:59 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:26:59 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
Message-ID: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>

installed MySQL/Ruby (2.7)
OS is CentOS release 4.2 (Final)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/4dd5e12d/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 01:33:12 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 14:33:12 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
Message-ID: <2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>

Even test only a single url which reads a few records from mysql and then
display, the memory usage still keep growing and never recover again.

The test tool is httperf, this is the command i used:
httperf --server 192.168.1.1 --port 81 --rate 15 --uri /user/ken --num-call
1 --num-conn 1000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/a3f08d05/attachment.html 

From carl.lerche at gmail.com  Tue Mar  6 02:39:56 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Mon, 5 Mar 2007 23:39:56 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
Message-ID: <ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>

Do you use ferret at all? I found that ferret (and acts_as_ferret)
cause the memory usage to grow to ~200MB a process. Can you list all
your installed gems or at least all the gems that you are using?

-carl


On 3/5/07, Ken Wei <2828628 at gmail.com> wrote:
> Even test only a single url which reads a few records from mysql and then
> display, the memory usage still keep growing and never recover again.
>
> The test tool is httperf, this is the command i used:
>  httperf --server 192.168.1.1 --port 81 --rate 15 --uri /user/ken --num-call
> 1 --num-conn 1000
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From 2828628 at gmail.com  Tue Mar  6 02:50:56 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 15:50:56 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
Message-ID: <2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>

*** LOCAL GEMS ***

actionmailer (1.3.2, 1.2.5, 1.1.5)
    Service layer for easy email delivery and testing.

actionpack (1.13.2, 1.12.5, 1.11.2)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.2, 1.1.6, 1.0.0)
    Web service support for Action Pack.

activerecord (1.15.2, 1.14.4, 1.13.2)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.1, 1.3.1, 1.2.5)
    Support and utility classes used by the Rails framework.

cgi_multipart_eof_fix (2.1)
    Fix an exploitable bug in CGI multipart parsing which affects Ruby
    <= 1.8.5 when multipart boundary attribute contains a non-halting
    regular expression string.

daemons (1.0.5, 0.4.4)
    A toolkit to create and control daemons in different ways

fastthread (0.6.4.1)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.2, 0.2.1)
    A plugin system based only on rubygems that uses dependencies only

hoe (1.1.7)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.5)
    a swift, liberal HTML parser with a fantastic library

htmltokenizer (1.0)
    A class to tokenize HTML.

mechanize (0.6.4)
    Mechanize provides automated web-browsing

memcache-client (1.2.0, 1.0.3)
    A Ruby memcached client

mongrel (1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (0.2.1)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

mysql (2.7)
    MySQL/Ruby provides the same functions for Ruby programs that the
    MySQL C API provides for C programs.

rails (1.2.2, 1.1.6, 1.0.0)
    Web-application framework with template engine, control-flow layer,
    and ORM.

rake (0.7.1, 0.7.0)
    Ruby based make-like utility.

rubyforge (0.4.0)
    A simplistic script which automates a limited set of rubyforge
    operations

rubyzip (0.9.1)
    rubyzip is a ruby module for reading and writing zip files

sources (0.0.1)
    This package provides download sources for remote gem installation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/85452c99/attachment.html 

From wayneeseguin at gmail.com  Tue Mar  6 06:31:46 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 6 Mar 2007 06:31:46 -0500
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
Message-ID: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>

If you are able try doing a

 > gem cleanup

to remove old versions of gems.

I've seen one case where that fixed such an issue.

   ~Wayne

On Mar 06, 2007, at 02:50 , Ken Wei wrote:

> *** LOCAL GEMS ***
>
> actionmailer (1.3.2, 1.2.5, 1.1.5)
>     Service layer for easy email delivery and testing.
>
> actionpack (1.13.2, 1.12.5, 1.11.2)
>     Web-flow and rendering framework putting the VC in MVC.
>
> actionwebservice (1.2.2, 1.1.6, 1.0.0)
>     Web service support for Action Pack.
>
> activerecord (1.15.2, 1.14.4, 1.13.2)
>     Implements the ActiveRecord pattern for ORM.
>
> activesupport (1.4.1, 1.3.1 , 1.2.5)
>     Support and utility classes used by the Rails framework.
>
> cgi_multipart_eof_fix (2.1)
>     Fix an exploitable bug in CGI multipart parsing which affects Ruby
>     <= 1.8.5 when multipart boundary attribute contains a non-halting
>     regular expression string.
>
> daemons (1.0.5, 0.4.4)
>     A toolkit to create and control daemons in different ways
>
> fastthread (0.6.4.1)
>     Optimized replacement for thread.rb primitives
>
> gem_plugin (0.2.2, 0.2.1)
>     A plugin system based only on rubygems that uses dependencies only
>
> hoe (1.1.7)
>     Hoe is a way to write Rakefiles much easier and cleaner.
>
> hpricot (0.5 )
>     a swift, liberal HTML parser with a fantastic library
>
> htmltokenizer (1.0)
>     A class to tokenize HTML.
>
> mechanize (0.6.4)
>     Mechanize provides automated web-browsing
>
> memcache-client ( 1.2.0, 1.0.3)
>     A Ruby memcached client
>
> mongrel (1.0.1)
>     A small fast HTTP library and server that runs Rails, Camping,  
> Nitro
>     and Iowa apps.
>
> mongrel_cluster (0.2.1)
>     Mongrel plugin that provides commands and Capistrano tasks for
>     managing multiple Mongrel processes.
>
> mysql (2.7)
>     MySQL/Ruby provides the same functions for Ruby programs that the
>     MySQL C API provides for C programs.
>
> rails (1.2.2, 1.1.6, 1.0.0)
>     Web-application framework with template engine, control-flow  
> layer,
>     and ORM.
>
> rake (0.7.1, 0.7.0)
>     Ruby based make-like utility.
>
> rubyforge (0.4.0)
>     A simplistic script which automates a limited set of rubyforge
>     operations
>
> rubyzip (0.9.1)
>     rubyzip is a ruby module for reading and writing zip files
>
> sources (0.0.1)
>     This package provides download sources for remote gem installation
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From thegiive at roodo.com  Tue Mar  6 07:32:49 2007
From: thegiive at roodo.com (giive chen)
Date: Tue, 6 Mar 2007 20:32:49 +0800
Subject: [Mongrel] My Mongrel on Linux is not stable
Message-ID: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>

Hello all
My app runs on Gentoo Linux with 2.6.18-gentoo-r6 and my CPU is
2.6.18-gentoo-r6.
The Mongrel version is 1.0.
I run mongrel cluster with 20 mongrel.

But after I lanuch my app, I found that there will be one rails application
error message in five or six request.
That means most of the request is normal but there will be 1/10 chance app
error.
But after I reload the error page, the status go to normal.
I found that some of the mongrel cluster crash but most of the cluster is
normal.
And the reverse proxy has 1/10 chance to redirect to the error mongrel.

After the mongrel cluster restart, everything goes to normal.
But one or two hours later, the status goes the same.

Could anyone give me some hint about what's going wrong?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/5348644d/attachment-0001.html 

From 2828628 at gmail.com  Tue Mar  6 07:49:48 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 20:49:48 +0800
Subject: [Mongrel] My Mongrel on Linux is not stable
In-Reply-To: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>
References: <77f9ba960703060432v2b833ad6pa1c82617a901e5bb@mail.gmail.com>
Message-ID: <2a0834610703060449y3673aab5s15498b31fb65fff2@mail.gmail.com>

Try to run less mongrel processes. How large is your total RAM?

Ken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/f51ffd92/attachment.html 

From 2828628 at gmail.com  Tue Mar  6 09:44:53 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Tue, 6 Mar 2007 22:44:53 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
Message-ID: <2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>

'gem cleanup' i did that, but still
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/b65bcedf/attachment.html 

From jgeiger at gmail.com  Tue Mar  6 10:50:52 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 09:50:52 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
Message-ID: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>

I've got issues with my rails application leaking memory as well. I
can say it's not Mongrel's fault, as I was able to duplicate the
situation in Webbrick.

My problem happens because I'm using monit to make sure my site stays
up, but in doing so, monit hits each of my mongrels every minute. I
thought the memory issues had to do with images, send_data or
something else, and what I found, is that on a site that does nothing
but respond to this monit controller, the memory grew and grew.

I'm guessing it has to do with the plugins I'm using, as when I tried
the same thing on a fresh rails application, the memory grew, but
capped off at about 35MB, where the full application loading all
plugins continued to grow until I killed it, never recovering memory.

So, for now, monit is the cause and solution to my memory problems. I
was thinking about trying to create a handler for mongrel that monit
can hit to verify that it's running, but then there's the possibility
that mongrel is up, but my application is down.

My other issue with using monit are the constant hits to the log
files, which logger.silence doesn't help (at least the methods I've
tried) If someone knows how to silence a controller completely, I'd
love to know.

Right now I'm a bit busy, but I think it would be a good test to add
my plugins one at a time to a fresh application and check the memory
usage after hitting it with a few thousand hits from apache bench.


On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> 'gem cleanup' i did that, but still
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From zedshaw at zedshaw.com  Tue Mar  6 14:08:24 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 6 Mar 2007 11:08:24 -0800
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
Message-ID: <20070306110824.8a3e1d54.zedshaw@zedshaw.com>

Hey Everyone,

Topfunky (Geoffry) has created a great PeepCode screencast on using
httperf to performance measure your web applications:

http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page-caching-and-httperf

http://peepcode.com/products/benchmarking-with-httperf

Topfunky put a ton of work into this and really got it right.  The
attention to detail is very good and he researched the subject
thoroughly.  I also spent time reviewing it so that he'd get the
statistics right, but he did a lot more than I expected.

The main thing that you'll get from his screencast is the actual
*process* of doing an analysis and then determining if there's
differences.  He shows graphs, takes notes, covers basic statistics,
and shows you how to figure out how fast your Mongrel setup can go.
It's much better watching someone else do it than reading a description.

Everyone who constantly asks about how to performance measure their web
apps should grab it and go through it.

Why am I pimping it so hard?  First, he's giving me a cut of the dough
and a brotha's gotta eat.  :-)  Second, it is probably the first
description of performance measurement and analysis I've seen that
actually gets it right.

Thanks for your time, and enjoy the day.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/

From alexey.verkhovsky at gmail.com  Tue Mar  6 12:11:40 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 Mar 2007 10:11:40 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>

So, memory leak is the problem, and monit is just highlighting it. Is that
correct?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/446d94fe/attachment.html 

From carl.lerche at gmail.com  Tue Mar  6 12:35:01 2007
From: carl.lerche at gmail.com (Carl Lerche)
Date: Tue, 6 Mar 2007 09:35:01 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>

Did you try adding GC.start in your application?

On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> I've got issues with my rails application leaking memory as well. I
> can say it's not Mongrel's fault, as I was able to duplicate the
> situation in Webbrick.
>
> My problem happens because I'm using monit to make sure my site stays
> up, but in doing so, monit hits each of my mongrels every minute. I
> thought the memory issues had to do with images, send_data or
> something else, and what I found, is that on a site that does nothing
> but respond to this monit controller, the memory grew and grew.
>
> I'm guessing it has to do with the plugins I'm using, as when I tried
> the same thing on a fresh rails application, the memory grew, but
> capped off at about 35MB, where the full application loading all
> plugins continued to grow until I killed it, never recovering memory.
>
> So, for now, monit is the cause and solution to my memory problems. I
> was thinking about trying to create a handler for mongrel that monit
> can hit to verify that it's running, but then there's the possibility
> that mongrel is up, but my application is down.
>
> My other issue with using monit are the constant hits to the log
> files, which logger.silence doesn't help (at least the methods I've
> tried) If someone knows how to silence a controller completely, I'd
> love to know.
>
> Right now I'm a bit busy, but I think it would be a good test to add
> my plugins one at a time to a fresh application and check the memory
> usage after hitting it with a few thousand hits from apache bench.
>
>
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > 'gem cleanup' i did that, but still
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

From rsanheim at gmail.com  Tue Mar  6 12:36:02 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 6 Mar 2007 11:36:02 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<69a2885c0703052153g222d78c4oc5a140d7bb2ea218@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
Message-ID: <fc113d400703060936m7383660oe07529330662919f@mail.gmail.com>

Can you do a dump of all the plugins you are using?  There are some
that are well known to be problematic with memory leaks.

- R0b

On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> I've got issues with my rails application leaking memory as well. I
> can say it's not Mongrel's fault, as I was able to duplicate the
> situation in Webbrick.
>
> My problem happens because I'm using monit to make sure my site stays
> up, but in doing so, monit hits each of my mongrels every minute. I
> thought the memory issues had to do with images, send_data or
> something else, and what I found, is that on a site that does nothing
> but respond to this monit controller, the memory grew and grew.
>
> I'm guessing it has to do with the plugins I'm using, as when I tried
> the same thing on a fresh rails application, the memory grew, but
> capped off at about 35MB, where the full application loading all
> plugins continued to grow until I killed it, never recovering memory.
>
> So, for now, monit is the cause and solution to my memory problems. I
> was thinking about trying to create a handler for mongrel that monit
> can hit to verify that it's running, but then there's the possibility
> that mongrel is up, but my application is down.
>
> My other issue with using monit are the constant hits to the log
> files, which logger.silence doesn't help (at least the methods I've
> tried) If someone knows how to silence a controller completely, I'd
> love to know.
>
> Right now I'm a bit busy, but I think it would be a good test to add
> my plugins one at a time to a fresh application and check the memory
> usage after hitting it with a few thousand hits from apache bench.
>
>
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > 'gem cleanup' i did that, but still
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From 2828628 at gmail.com  Tue Mar  6 12:54:43 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 01:54:43 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
Message-ID: <2a0834610703060954q389582ccvdcdc6eb094ef773d@mail.gmail.com>

> Did you try adding GC.start in your application?

yep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/58be976b/attachment.html 

From jgeiger at gmail.com  Tue Mar  6 13:24:06 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 12:24:06 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
Message-ID: <466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>

Here are the plugins that were on the application when I just tried
loading a single controller, which ended up hitting an 80MB limit
after about 8 hours on all 4 mongrels running rails 1.2.2. They all
restarted within minutes of each other, which was interesting.

acts_as_ferret
arts
authorization
custom-err-msg
exception_notification
flex_image
has_many_polymorphs
http_url_validation
paginating_find
rails_rcov
resource_feeder (added after test)
restful_authentication
routing_navigator
simply_helpful
sql_session_store
timed_fragment_cache

The application I have in development that restarts every few days has
the following plugins.
acts_as_authenticated
acts_as_rateable
arts
assert_select
authorization
browser_filters
custom-err-msg
debug_view_helper
exception_notification
flex_image
paginating_find
rails_rcov
responsible_markup
simple_http_auth
timed_fragment_cache
white_list

I ran the tests with and without GC.start in the controller.
GC.start kicked off in the production application when I do a send_data call.




On 3/6/07, Carl Lerche <carl.lerche at gmail.com> wrote:
> Did you try adding GC.start in your application?
>
> On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
> > I've got issues with my rails application leaking memory as well. I
> > can say it's not Mongrel's fault, as I was able to duplicate the
> > situation in Webbrick.
> >
> > My problem happens because I'm using monit to make sure my site stays
> > up, but in doing so, monit hits each of my mongrels every minute. I
> > thought the memory issues had to do with images, send_data or
> > something else, and what I found, is that on a site that does nothing
> > but respond to this monit controller, the memory grew and grew.
> >
> > I'm guessing it has to do with the plugins I'm using, as when I tried
> > the same thing on a fresh rails application, the memory grew, but
> > capped off at about 35MB, where the full application loading all
> > plugins continued to grow until I killed it, never recovering memory.
> >
> > So, for now, monit is the cause and solution to my memory problems. I
> > was thinking about trying to create a handler for mongrel that monit
> > can hit to verify that it's running, but then there's the possibility
> > that mongrel is up, but my application is down.
> >
> > My other issue with using monit are the constant hits to the log
> > files, which logger.silence doesn't help (at least the methods I've
> > tried) If someone knows how to silence a controller completely, I'd
> > love to know.
> >
> > Right now I'm a bit busy, but I think it would be a good test to add
> > my plugins one at a time to a fresh application and check the memory
> > usage after hitting it with a few thousand hits from apache bench.
> >
> >
> > On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> > > 'gem cleanup' i did that, but still
> > >
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
> --
> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From mongrel at philip.pjkh.com  Tue Mar  6 14:08:32 2007
From: mongrel at philip.pjkh.com (Philip Hallstrom)
Date: Tue, 6 Mar 2007 13:08:32 -0600 (CST)
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<ab90312e0703060935j2d1ac76flcaf25a220d22f926@mail.gmail.com>
	<466af3440703061024n7f078bd3q6c0bd774b445a76c@mail.gmail.com>
Message-ID: <20070306130753.T42542@bravo.pjkh.com>

> The application I have in development that restarts every few days has
> the following plugins.
> acts_as_authenticated
> acts_as_rateable
> arts
> assert_select
> authorization
> browser_filters
> custom-err-msg
> debug_view_helper
> exception_notification
> flex_image

flex_image uses rmagick... which folks have lots of issues with...

> paginating_find
> rails_rcov
> responsible_markup
> simple_http_auth
> timed_fragment_cache
> white_list
>
> I ran the tests with and without GC.start in the controller.
> GC.start kicked off in the production application when I do a send_data call.
>
>
>
>
> On 3/6/07, Carl Lerche <carl.lerche at gmail.com> wrote:
>> Did you try adding GC.start in your application?
>>
>> On 3/6/07, Joey Geiger <jgeiger at gmail.com> wrote:
>>> I've got issues with my rails application leaking memory as well. I
>>> can say it's not Mongrel's fault, as I was able to duplicate the
>>> situation in Webbrick.
>>>
>>> My problem happens because I'm using monit to make sure my site stays
>>> up, but in doing so, monit hits each of my mongrels every minute. I
>>> thought the memory issues had to do with images, send_data or
>>> something else, and what I found, is that on a site that does nothing
>>> but respond to this monit controller, the memory grew and grew.
>>>
>>> I'm guessing it has to do with the plugins I'm using, as when I tried
>>> the same thing on a fresh rails application, the memory grew, but
>>> capped off at about 35MB, where the full application loading all
>>> plugins continued to grow until I killed it, never recovering memory.
>>>
>>> So, for now, monit is the cause and solution to my memory problems. I
>>> was thinking about trying to create a handler for mongrel that monit
>>> can hit to verify that it's running, but then there's the possibility
>>> that mongrel is up, but my application is down.
>>>
>>> My other issue with using monit are the constant hits to the log
>>> files, which logger.silence doesn't help (at least the methods I've
>>> tried) If someone knows how to silence a controller completely, I'd
>>> love to know.
>>>
>>> Right now I'm a bit busy, but I think it would be a good test to add
>>> my plugins one at a time to a fresh application and check the memory
>>> usage after hitting it with a few thousand hits from apache bench.
>>>
>>>
>>> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
>>>> 'gem cleanup' i did that, but still
>>>>
>>>> _______________________________________________
>>>> Mongrel-users mailing list
>>>> Mongrel-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>>
>>> _______________________________________________
>>> Mongrel-users mailing list
>>> Mongrel-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>>
>>
>>
>> --
>> EPA Rating: 3000 Lines of Code / Gallon (of coffee)
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From public at misuse.org  Tue Mar  6 14:12:00 2007
From: public at misuse.org (Steve Midgley)
Date: Tue, 06 Mar 2007 11:12:00 -0800
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
	Shaw)
In-Reply-To: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
Message-ID: <20070306192512.E547D5242072@rubyforge.org>

Hi,

Thanks Zed - this is very interesting. One item in particular caught my 
eye: Does anyone on this list have any comments or validation that 
Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a 
link that purports what looks like really horrible performance and 
memory characteristics for Rails 1.2.1, even v. 1.1.6:

http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

Did Rails 1.2.2 fix anything in this regard? (I didn't see any mention 
of performance improvements in the dev notes).

There were some nice feature upgrades in 1.2.1 that I'm using, but it 
would be great to know that performance is now a real issue (and 
rolling back would fix it).

Any information?

Thanks,

Steve


>Message: 4
>Date: Tue, 6 Mar 2007 11:08:24 -0800
>From: "Zed A. Shaw" <zedshaw at zedshaw.com>
>Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
>To: mongrel-users at rubyforge.org
>Message-ID: <20070306110824.8a3e1d54.zedshaw at zedshaw.com>
>Content-Type: text/plain; charset=US-ASCII
>
>Hey Everyone,
>
>Topfunky (Geoffry) has created a great PeepCode screencast on using
>httperf to performance measure your web applications:
>
>http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page-caching-and-httperf
>
>http://peepcode.com/products/benchmarking-with-httperf
>
>Topfunky put a ton of work into this and really got it right.  The
>attention to detail is very good and he researched the subject
>thoroughly.  I also spent time reviewing it so that he'd get the
>statistics right, but he did a lot more than I expected.
>
>The main thing that you'll get from his screencast is the actual
>*process* of doing an analysis and then determining if there's
>differences.  He shows graphs, takes notes, covers basic statistics,
>and shows you how to figure out how fast your Mongrel setup can go.
>It's much better watching someone else do it than reading a 
>description.
>
>Everyone who constantly asks about how to performance measure their 
>web
>apps should grab it and go through it.
>
>Why am I pimping it so hard?  First, he's giving me a cut of the dough
>and a brotha's gotta eat.  :-)  Second, it is probably the first
>description of performance measurement and analysis I've seen that
>actually gets it right.
>
>Thanks for your time, and enjoy the day.
>
>--
>Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
>http://www.zedshaw.com/
>http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>http://mongrel.rubyforge.org/
>


From joost at spacebabies.nl  Tue Mar  6 15:13:06 2007
From: joost at spacebabies.nl (joost baaij)
Date: Tue, 6 Mar 2007 21:13:06 +0100
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
	Shaw)
In-Reply-To: <20070306192512.E547D5242072@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
Message-ID: <A0C817B9-06FA-4541-A699-7E3AE46E13AA@spacebabies.nl>

Hmm, reading that I am growing more suspicious. My ram-related woes  
appeared when Rails 1.2 hit the stage. But I also saw a hefty  
increase in traffic so was quick to blame it on that.


Op 6-mrt-2007, om 20:12 heeft Steve Midgley het volgende geschreven:

> Hi,
>
> Thanks Zed - this is very interesting. One item in particular  
> caught my
> eye: Does anyone on this list have any comments or validation that
> Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a
> link that purports what looks like really horrible performance and
> memory characteristics for Rails 1.2.1, even v. 1.1.6:
>
> http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading- 
> frameworks/
>
> Did Rails 1.2.2 fix anything in this regard? (I didn't see any mention
> of performance improvements in the dev notes).
>
> There were some nice feature upgrades in 1.2.1 that I'm using, but it
> would be great to know that performance is now a real issue (and
> rolling back would fix it).
>
> Any information?
>
> Thanks,
>
> Steve
>
>
>> Message: 4
>> Date: Tue, 6 Mar 2007 11:08:24 -0800
>> From: "Zed A. Shaw" <zedshaw at zedshaw.com>
>> Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast
>> To: mongrel-users at rubyforge.org
>> Message-ID: <20070306110824.8a3e1d54.zedshaw at zedshaw.com>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> Hey Everyone,
>>
>> Topfunky (Geoffry) has created a great PeepCode screencast on using
>> httperf to performance measure your web applications:
>>
>> http://nubyonrails.topfunky.com/articles/2007/03/05/peepcode-page- 
>> caching-and-httperf
>>
>> http://peepcode.com/products/benchmarking-with-httperf
>>
>> Topfunky put a ton of work into this and really got it right.  The
>> attention to detail is very good and he researched the subject
>> thoroughly.  I also spent time reviewing it so that he'd get the
>> statistics right, but he did a lot more than I expected.
>>
>> The main thing that you'll get from his screencast is the actual
>> *process* of doing an analysis and then determining if there's
>> differences.  He shows graphs, takes notes, covers basic statistics,
>> and shows you how to figure out how fast your Mongrel setup can go.
>> It's much better watching someone else do it than reading a
>> description.
>>
>> Everyone who constantly asks about how to performance measure their
>> web
>> apps should grab it and go through it.
>>
>> Why am I pimping it so hard?  First, he's giving me a cut of the  
>> dough
>> and a brotha's gotta eat.  :-)  Second, it is probably the first
>> description of performance measurement and analysis I've seen that
>> actually gets it right.
>>
>> Thanks for your time, and enjoy the day.
>>
>> --
>> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
>> http://www.zedshaw.com/
>> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>> http://mongrel.rubyforge.org/
>>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-- 
www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam




From jgeiger at gmail.com  Tue Mar  6 15:34:34 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 6 Mar 2007 14:34:34 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
Message-ID: <466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>

> flex_image uses rmagick... which folks have lots of issues with...

I re-wrote the bits of flex_image that I use to use mini-magick and
it's working quite nicely.
I did that when the whole discussion of "RMagick bad" came up a couple
of months ago.

On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> So, memory leak is the problem, and monit is just highlighting it. Is that
> correct?

For me, yes. I'm not exactly sure what is happening, but on my current
application, the only controller that was hit overnight was the monit
checker, which was enough to cause the leak.

Here's a copy of the controller, which I've tried to strip down as
much as possible. (On my current production app, it's doing 10k
requests per second :)

class MonitController < ActionController::Base
  session :off
##   this is used by the monitoring scripts to see if the mongrel is
up and running
  def index
  end
end

From ezmobius at gmail.com  Tue Mar  6 16:17:45 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 6 Mar 2007 13:17:45 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052223s5287b28cs10af9f7e40b5c63@mail.gmail.com>
	<2a0834610703052226s112d6d14ge86fc31409c2f49b@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
Message-ID: <3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>


On Mar 6, 2007, at 12:34 PM, Joey Geiger wrote:

>> flex_image uses rmagick... which folks have lots of issues with...
>
> I re-wrote the bits of flex_image that I use to use mini-magick and
> it's working quite nicely.
> I did that when the whole discussion of "RMagick bad" came up a couple
> of months ago.
>
> On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
>> So, memory leak is the problem, and monit is just highlighting it.  
>> Is that
>> correct?
>
> For me, yes. I'm not exactly sure what is happening, but on my current
> application, the only controller that was hit overnight was the monit
> checker, which was enough to cause the leak.
>
> Here's a copy of the controller, which I've tried to strip down as
> much as possible. (On my current production app, it's doing 10k
> requests per second :)
>
> class MonitController < ActionController::Base
>   session :off
> ##   this is used by the monitoring scripts to see if the mongrel is
> up and running
>   def index
>   end
> end


	I have seen weird behavior from having monit check with a http  
request. It woudl cause weird issues and mem leaks. I have since  
removed any http checks from all my monit recipes and used an  
external siteuptime monitoring for http status check. Monit just  
watches memory and cpu usage and restarts dead or bloated mongrels.

	It's just a fact of life with large rails applications, some of them  
just like to keep using memory as much as possible. I have found that  
restarting mongrels that go over 110Mb for a few cycles will keep  
things in check pretty well. This is for 64bit systems where memory  
usage is higher then on 32 bit systems.

	Here is a monit recipe I am using on a large number of servers that  
seems to work very well.

set httpd port 9111
     allow localhost

set daemon 60
set logfile /data/username/shared/log/monit.log
set mail-format {from:info at engineyard.com}
set mailserver smtp.engineyard.com
set alert eymonit at gmail.com

check process mongrel_username_0
   with pidfile /data/username/shared/log/mongrel.5000.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5000  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5000  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_username_1
   with pidfile /data/username/shared/log/mongrel.5001.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5001  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5001  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_username_2
   with pidfile /data/username/shared/log/mongrel.5002.pid
   start program = "/data/username/shared/bin/start_mongrel.sh 5002  
username"
   stop program = "/data/username/shared/bin/stop_mongrel.sh 5002  
username"
   if totalmem is greater than 110.0 MB for 4 cycles then  
restart       # eating up memory?
   if cpu is greater than 50% for 2 cycles then  
alert                  # send an email to admin
   if cpu is greater than 80% for 3 cycles then  
restart                # hung process?
   if loadavg(5min) greater than 10 for 8 cycles then  
restart          # bad, bad, bad
   if 10 restarts within 10 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel


Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From rsanheim at gmail.com  Tue Mar  6 16:23:20 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Tue, 6 Mar 2007 15:23:20 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
Message-ID: <fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>

On 3/6/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Mar 6, 2007, at 12:34 PM, Joey Geiger wrote:
>
> >> flex_image uses rmagick... which folks have lots of issues with...
> >
> > I re-wrote the bits of flex_image that I use to use mini-magick and
> > it's working quite nicely.
> > I did that when the whole discussion of "RMagick bad" came up a couple
> > of months ago.
> >
> > On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> >> So, memory leak is the problem, and monit is just highlighting it.
> >> Is that
> >> correct?
> >
> > For me, yes. I'm not exactly sure what is happening, but on my current
> > application, the only controller that was hit overnight was the monit
> > checker, which was enough to cause the leak.
> >
> > Here's a copy of the controller, which I've tried to strip down as
> > much as possible. (On my current production app, it's doing 10k
> > requests per second :)
> >
> > class MonitController < ActionController::Base
> >   session :off
> > ##   this is used by the monitoring scripts to see if the mongrel is
> > up and running
> >   def index
> >   end
> > end
>
>
>         I have seen weird behavior from having monit check with a http
> request. It woudl cause weird issues and mem leaks. I have since
> removed any http checks from all my monit recipes and used an
> external siteuptime monitoring for http status check. Monit just
> watches memory and cpu usage and restarts dead or bloated mongrels.
>
>         It's just a fact of life with large rails applications, some of them
> just like to keep using memory as much as possible. I have found that
> restarting mongrels that go over 110Mb for a few cycles will keep
> things in check pretty well. This is for 64bit systems where memory
> usage is higher then on 32 bit systems.
>
>         Here is a monit recipe I am using on a large number of servers that
> seems to work very well.
>
> set httpd port 9111
>      allow localhost
>
> set daemon 60
> set logfile /data/username/shared/log/monit.log
> set mail-format {from:info at engineyard.com}
> set mailserver smtp.engineyard.com
> set alert eymonit at gmail.com
>
> check process mongrel_username_0
>    with pidfile /data/username/shared/log/mongrel.5000.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5000
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5000
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_username_1
>    with pidfile /data/username/shared/log/mongrel.5001.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5001
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5001
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_username_2
>    with pidfile /data/username/shared/log/mongrel.5002.pid
>    start program = "/data/username/shared/bin/start_mongrel.sh 5002
> username"
>    stop program = "/data/username/shared/bin/stop_mongrel.sh 5002
> username"
>    if totalmem is greater than 110.0 MB for 4 cycles then
> restart       # eating up memory?
>    if cpu is greater than 50% for 2 cycles then
> alert                  # send an email to admin
>    if cpu is greater than 80% for 3 cycles then
> restart                # hung process?
>    if loadavg(5min) greater than 10 for 8 cycles then
> restart          # bad, bad, bad
>    if 10 restarts within 10 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel

Ezra,

What do you use for uptime monitoring?  I haven't found anything out
of the box that can check often enough (ie at least every minute).

- Rob

From ezmobius at gmail.com  Tue Mar  6 16:38:12 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 6 Mar 2007 13:38:12 -0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052233u6377a83dtff0acd376f9a1afd@mail.gmail.com>
	<ab90312e0703052339u3a5f90acl107e184e1a08dcaf@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
Message-ID: <64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>


On Mar 6, 2007, at 1:23 PM, Rob Sanheim wrote:

> On 3/6/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> snip
>
> Ezra,
>
> What do you use for uptime monitoring?  I haven't found anything out
> of the box that can check often enough (ie at least every minute).
>
> - Rob


Rob-

	We use http://siteuptime.com/ for an external site health check that  
checks every 2 minutes from SF, NYC, Florida and London. We also have  
health checking going on in our load balancers with alerts in closer  
to real time.


Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From alexey.verkhovsky at gmail.com  Tue Mar  6 17:31:13 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 Mar 2007 15:31:13 -0700
Subject: [Mongrel] Multiple apps on the same server,
	all should be able to survive slashdotting
In-Reply-To: <45EBC251.2060807@gmail.com>
References: <3945c4270703021249r6a57e2e1t2b656d34d3d323b7@mail.gmail.com>
	<45EBC251.2060807@gmail.com>
Message-ID: <3945c4270703061431p1b77f33amcb7205d0e7619fca@mail.gmail.com>

> My personal experience points to the contrary, using FCGI listeners (if
> you have the option of dumping apache for lighttpd) works well. Just spawn
> the fcgi listeners externally from script/process/spinner


I've seen and heard many enough conversations along the lines of "FastCGI
leaves zombie Ruby processes floating around", 6 to 12 months ago.
Sure, you can harvest those things with a Cron job, but doesn't this smell
funny?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070306/46680b91/attachment.html 

From 2828628 at gmail.com  Wed Mar  7 00:06:17 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 13:06:17 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703052350y3d8662a5j81015dc937f720f@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
Message-ID: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>

I created a new rails app named 'test' which containing only a controller
and an action .
Here is the controller:

class MyTestController < ApplicationController

        def index
                render_text 'Hello!'
        end

end

I keeped the setup as the same as before. Then i ran a single mongrel server
which listening on 3000 by default, and used httperf to hit the action:

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
1 --num-conn 10000

The memory usage of the mongrel server grows from 20M to 144M in 20 seconds,
it's crazy!
And i tryed Lighttpd + FastCGI to test this case, it works well. Then i
think about if i need to roll back to the fastcgi way? is the mongrel the
future of the rails community?

confused! confused! confused!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/dc3bb504/attachment.html 

From 2828628 at gmail.com  Wed Mar  7 00:16:48 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 13:16:48 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
Message-ID: <2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>

is mongrel still far from production ready? or did i make something wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/aab628a2/attachment.html 

From kylekochis at gmail.com  Wed Mar  7 01:12:16 2007
From: kylekochis at gmail.com (Kyle Kochis)
Date: Tue, 6 Mar 2007 23:12:16 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<2a0834610703062116u458d25aak9657fae278931262@mail.gmail.com>
Message-ID: <6a7034b0703062212g5d406a81u8b3fd52c7310a271@mail.gmail.com>

There has got to be something seriously wrong with your stack/install
although I am not knowledgeable enough to tell you where to start
looking.
Kyle Kochis

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
> is mongrel still far from production ready? or did i make something wrong?
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From alexey.verkhovsky at gmail.com  Wed Mar  7 01:55:06 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 Mar 2007 00:55:06 -0600
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
Message-ID: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>

On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:
Hey,

Looks like we are on the same stage of the learning curve about this stuff.
So, let's share our discoveries with the rest of the world :)

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
> 1 --num-conn 10000
>
> The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's


This is exactly what Mongrel does when it cannot cope with the incoming
traffic. I've discovered the same effect today.

You are definitely overloading it with 80 requests per second. After all,
it's a single-threaded instance of a fairly CPU-heavy framework. With no
page caching it should cope with ~10 to 30 requests per second max.

The crappy part about this, after the overload condition is off, the Mongrel
process stays at 150Mb. Not a problem when you are hosting one app on the
box, but becomes a problem when it's ten.

By the way, check the errors section of httperf report, and the
production.log. See if there are "fd_unavailable" socket errors in the
former, and probably some complaints about "too many files open" in the
latter. If there are, you need to either increase the number of file
descriptors in the Linux kernel, or decrease the max number of open sockets
in the Mongrel(s), with -n option. I don't know if it solves the "RAM
footprint growing to 150 Mb" problem... I will know it first thing tomorrow
morning :)

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/ea2b19f4/attachment.html 

From jacob at jacobatzen.dk  Wed Mar  7 03:21:23 2007
From: jacob at jacobatzen.dk (Jacob Atzen)
Date: Wed, 7 Mar 2007 09:21:23 +0100
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
References: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
Message-ID: <20070307082123.GB74355@apoc.jacobatzen.dk>

On Wed, Mar 07, 2007 at 12:55:06AM -0600, Alexey Verkhovsky wrote:
> This is exactly what Mongrel does when it cannot cope with the incoming
> traffic. I've discovered the same effect today.
> 
> You are definitely overloading it with 80 requests per second. After all,
> it's a single-threaded instance of a fairly CPU-heavy framework. With no
> page caching it should cope with ~10 to 30 requests per second max.
> 
> The crappy part about this, after the overload condition is off, the Mongrel
> process stays at 150Mb. Not a problem when you are hosting one app on the
> box, but becomes a problem when it's ten.

I've had some success reducing the number of processors. Try reducing
this somewhat and see if it helps.

-- 
Cheers,
- Jacob Atzen

From 2828628 at gmail.com  Wed Mar  7 05:26:47 2007
From: 2828628 at gmail.com (Ken Wei)
Date: Wed, 7 Mar 2007 18:26:47 +0800
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <20070307082123.GB74355@apoc.jacobatzen.dk>
References: <C1D3BA71-D8B1-4E58-8D80-13234E050A24@gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<20070307082123.GB74355@apoc.jacobatzen.dk>
Message-ID: <2a0834610703070226y17e716c7tbf366f3d3c6d9529@mail.gmail.com>

>Looks like we are on the same stage of the learning curve about this stuff.
So, let's share our discoveries with >the rest of the world :)

httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test --num-call
> 1 --num-conn 10000
>
> The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's


>This is exactly what Mongrel does when it cannot cope with the incoming
traffic. I've discovered the same >effect today.

>You are definitely overloading it with 80 requests per second. After all,
it's a single-threaded instance of a fairly >CPU-heavy framework. With no
page caching it should cope with ~10 to 30 requests per second max.

Yes, it's overload with message 'Too many open files...'. Anyway this test
doesn't shoot the heart of this issue. I should make the other one later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/832cc7ca/attachment.html 

From wyhaines at gmail.com  Wed Mar  7 06:14:57 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 7 Mar 2007 04:14:57 -0700
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
Message-ID: <f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>

On 3/6/07, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> On 3/6/07, Ken Wei <2828628 at gmail.com> wrote:

> Looks like we are on the same stage of the learning curve about this stuff.
> So, let's share our discoveries with the rest of the world :)
>
> > httperf --server 192.168.1.1 --port 3000 --rate 80 --uri /my_test
> --num-call 1 --num-conn 10000
> >
> > The memory usage of the mongrel server grows from 20M to 144M in 20
> seconds, it's
>
> This is exactly what Mongrel does when it cannot cope with the incoming
> traffic. I've discovered the same effect today.

I think it's fair to make a distinction here.

What is probably happening is that Rails is not keeping up with that
80 reqs/second rate; it's not Mongrel.  On any remotely modern
hardware, Mongrel will easily keep that pace itself.

However, the net effect is that Mongrel creates a thread for each
accepted connection.  These threads are fairly memory intensive, since
each one carries with it a fair amount of context, yet all they are
doing is sitting there sleeping behind a mutex, waiting for their
chance to wake up and run their request through the Rails handler.

> By the way, check the errors section of httperf report, and the
> production.log. See if there are "fd_unavailable" socket errors in the
> former, and probably some complaints about "too many files open" in the
> latter. If there are, you need to either increase the number of file
> descriptors in the Linux kernel, or decrease the max number of open sockets
> in the Mongrel(s), with -n option. I don't know if it solves the "RAM
> footprint growing to 150 Mb" problem... I will know it first thing tomorrow
> morning :)

No.  That is probably happening because of the file descriptor limit
in Ruby.  Your Mongrel has accepted as many connections as Ruby can
handle; it is out of descriptors.


Kirk Haines

From rancor at mindspring.com  Wed Mar  7 08:21:33 2007
From: rancor at mindspring.com (Jim Powers)
Date: Wed, 07 Mar 2007 08:21:33 -0500
Subject: [Mongrel] [PIMP] Topfunky's httperf PeepCode screencast (Zed A.
 Shaw)
In-Reply-To: <20070306192512.E547D5242072@rubyforge.org>
References: <mailman.97.1173205452.25682.mongrel-users@rubyforge.org>
	<20070306192512.E547D5242072@rubyforge.org>
Message-ID: <20070307082133.08996836@nomadII.powershouse.bogus>

On Tue, 06 Mar 2007 11:12:00 -0800
Steve Midgley <public at misuse.org> wrote:

> Thanks Zed - this is very interesting. One item in particular caught
> my eye: Does anyone on this list have any comments or validation that 
> Rails 1.2.1 is 2-4 times as slow as Rails 1.1.6? Topfunky provided a 
> link that purports what looks like really horrible performance and 
> memory characteristics for Rails 1.2.1, even v. 1.1.6:
> 
> http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/
> 
> Did Rails 1.2.2 fix anything in this regard? (I didn't see any
> mention of performance improvements in the dev notes).
> 
> There were some nice feature upgrades in 1.2.1 that I'm using, but it 
> would be great to know that performance is now a real issue (and 
> rolling back would fix it).

I have been doing my own investigations into this issue, in particular,
I'm looking for at least one cause of an unacceptable slowdown that I
have been encountering (I will now go back and redo the tests under
1.1.6 for comparison).  In particular I've been observing *really poor*
performance with ActiveRecord.  In particular, when I run with the
profiler I'm seeing a stunning number of calls to the inflector methods.

Here "my" deal:

I have a class that only inherits from ActiveRecord so I get some SQL
logging.  It actually is using the driver directly (in this case
unixODBC) because I am calling a stored procedure that returns multiple
result sets (something ActiveRecord cannot do). So I have a "find"
method that returns a simple collection of hashes, nothing more.  I
benchmarked 100 calls and found that the inflector methods were the
overall most time consuming part of the effort with over 40K calls!
Now, the stuff returned form the 'find' call are not even derived from
ActiveRecord so I would expect a total of 0 (zero) such calls.

The best I can tell is that there must be a whole lotta new after
filters in 1.2.x doing lots of Rails magic.

Still investigating.

Jim Powers

From joe_lester at sweetwater.com  Wed Mar  7 08:02:23 2007
From: joe_lester at sweetwater.com (Joe Lester)
Date: Wed, 7 Mar 2007 08:02:23 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
Message-ID: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>

My rails web app (rails 1.2.1) uploads an image from a Java applet by  
encoding it into the URL. This works fine when I'm using Webrick. I'm  
trying out Mongrel today, and I'm getting an error in Safari that  
says ?lost network connection? (NSURLErrorDomain:-1005). I get  
something similar in Firefox. Is there a way to make Mongrel accept a  
really long URL like this?

Thanks. Joe.

I'm encoding the 512 x 512 jpeg image as Base64. The long URL is  
something like...

http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD% 
2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ 
EBAQEBAQEBAQEBAQEBAQH% 
2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ 
EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB% 
2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL% 
2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA 
kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd 
4eXqDhIWGh4iJipKTlJWW......... [much more]

When the URL is long, the action is not called in rails. But, if I  
remove the image from the URL, then the action is called.

From rancor at mindspring.com  Wed Mar  7 08:03:59 2007
From: rancor at mindspring.com (Jim Powers)
Date: Wed, 07 Mar 2007 08:03:59 -0500
Subject: [Mongrel] Memory leaks in my site
In-Reply-To: <f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
References: <2a0834610703052111h7613c3e0i11dab7fdd521450c@mail.gmail.com>
	<2a0834610703060644q37e551dax487dd522d08c5e77@mail.gmail.com>
	<466af3440703060750x4668099ak4ab4255977cc9dac@mail.gmail.com>
	<3945c4270703060911y1e9c1d9bt4275908f98aad89f@mail.gmail.com>
	<466af3440703061234y5b3ef725m83f365d7819b32ec@mail.gmail.com>
	<3CEE0949-8D92-4240-908A-54A1C9E9F5F5@gmail.com>
	<fc113d400703061323y3ca28f97r13e1094eb8fc3e76@mail.gmail.com>
	<64015155-F98D-421E-B2C2-613BA11BF493@brainspl.at>
	<2a0834610703062106t68c6db78y90091ba8a1be91ae@mail.gmail.com>
	<3945c4270703062255w5ab2a2f1yf2deb0aa97dcac30@mail.gmail.com>
	<f4cd26df0703070314o97f5745qa7d9a14df3ce9b01@mail.gmail.com>
Message-ID: <20070307080359.64394ef6@nomadII.powershouse.bogus>

On Wed, 7 Mar 2007 04:14:57 -0700
"Kirk Haines" <wyhaines at gmail.com> wrote:

> > By the way, check the errors section of httperf report, and the
> > production.log. See if there are "fd_unavailable" socket errors in
> > the former, and probably some complaints about "too many files
> > open" in the latter. If there are, you need to either increase the
> > number of file descriptors in the Linux kernel, or decrease the max
> > number of open sockets in the Mongrel(s), with -n option. I don't
> > know if it solves the "RAM footprint growing to 150 Mb" problem...
> > I will know it first thing tomorrow morning :)
> 
> No.  That is probably happening because of the file descriptor limit
> in Ruby.  Your Mongrel has accepted as many connections as Ruby can
> handle; it is out of descriptors.

What file descriptor limit are you referring to?  A typical Linux
<default> ulimit on file descriptors is 1024, which should be more than
enough for the test Ken is performing.

Also, I would recommend doing a test where you separate Mongrel from
Rails.  Use a simple Mongrel handler like the one found here:

http://mongrel.rubyforge.org/rdoc/index.html

require 'mongrel'

 class SimpleHandler < Mongrel::HttpHandler
    def process(request, response)
      response.start(200) do |head,out|
        head["Content-Type"] = "text/plain"
        out.write("hello!\n")
      end
    end
 end

 h = Mongrel::HttpServer.new("0.0.0.0", "3000")
 h.register("/test", SimpleHandler.new)
 h.register("/files", Mongrel::DirHandler.new("."))
 h.run.join

This will possibly narrow down the problem area.  If Mongrel itself is
to blame then you should still see lots-o-memory growth.  Or it is the
interface with Rails that is causing the problem.

Jim Powers

From eden at mojiti.com  Wed Mar  7 09:47:27 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 7 Mar 2007 22:47:27 +0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <1dd361e10703070647w69302ea7o8f0bbe69ed7c1785@mail.gmail.com>

Whoa... why don't you include the image in a POST body?

Technically there's no URL limit, but sending images using URL params sounds
like a candidate for one of the blogs that I read...

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
>
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/4211982e/attachment.html 

From pberry at gmail.com  Wed Mar  7 09:49:15 2007
From: pberry at gmail.com (Patrick Berry)
Date: Wed, 7 Mar 2007 06:49:15 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>

Is it just me or is that an insane amount of data to send via GET?  Mongrel
is pretty strict about how clients use HTTP, so check your mongrel logs.

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
>
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/f5447d44/attachment.html 

From pberry at gmail.com  Wed Mar  7 10:01:22 2007
From: pberry at gmail.com (Patrick Berry)
Date: Wed, 7 Mar 2007 07:01:22 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
	<ef13ff170703070649h5aff7917ga7bc056e1de7d448@mail.gmail.com>
Message-ID: <ef13ff170703070701l5e880f69j61e7abdd8ab3ee96@mail.gmail.com>

The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

My bad...still...that's a lot of data.

On 3/7/07, Patrick Berry <pberry at gmail.com> wrote:
>
> Is it just me or is that an insane amount of data to send via GET?
> Mongrel is pretty strict about how clients use HTTP, so check your mongrel
> logs.
>
> On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> >
> > My rails web app (rails 1.2.1) uploads an image from a Java applet by
> > encoding it into the URL. This works fine when I'm using Webrick. I'm
> > trying out Mongrel today, and I'm getting an error in Safari that
> > says "lost network connection" (NSURLErrorDomain:-1005). I get
> > something similar in Firefox. Is there a way to make Mongrel accept a
> > really long URL like this?
> >
> > Thanks. Joe.
> >
> > I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> > something like...
> >
> > http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%<http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%25>
> > 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> >
> > EBAQEBAQEBAQEBAQEBAQH%
> > 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> > EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> > 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> > 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> >
> > kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> > 4eXqDhIWGh4iJipKTlJWW......... [much more]
> >
> > When the URL is long, the action is not called in rails. But, if I
> > remove the image from the URL, then the action is called.
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/b7cd1bed/attachment-0001.html 

From francois.beausoleil at gmail.com  Wed Mar  7 10:15:19 2007
From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=)
Date: Wed, 7 Mar 2007 10:15:19 -0500
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <41d5fadf0703070715v20b7169bt592b4f7a511f213c@mail.gmail.com>

Hello Joe,

2007/3/7, Joe Lester <joe_lester at sweetwater.com>:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?

Yes, Mongrel will kill the request because it thinks you're trying to
attack it.  Why can't you POST the data instead ?  This is what POST
was intended to do.

Bye !
-- 
Fran?ois Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/

From rsanheim at gmail.com  Wed Mar  7 10:17:14 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 7 Mar 2007 09:17:14 -0600
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <fc113d400703070717n7b23c5b5k32f6dc233526f1b0@mail.gmail.com>

You realize that some browsers will complain about this, right?
Having very long URLs is generally a bad idea.

see also: http://www.boutell.com/newfaq/misc/urllength.html

- Rob

On 3/7/07, Joe Lester <joe_lester at sweetwater.com> wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by
> encoding it into the URL. This works fine when I'm using Webrick. I'm
> trying out Mongrel today, and I'm getting an error in Safari that
> says "lost network connection" (NSURLErrorDomain:-1005). I get
> something similar in Firefox. Is there a way to make Mongrel accept a
> really long URL like this?
>
> Thanks. Joe.
>
> I'm encoding the 512 x 512 jpeg image as Base64. The long URL is
> something like...
>
> http://localhost/account/upload?image=%2F9j%2F4AAQSkZJRgABAQAAAQABAAD%
> 2F2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%
> 2F2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
> EBAQEBAQEBAQEBAQEBAQH%2FwAARCAIAAgADASIAAhEBAxEB%
> 2F8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL%
> 2F8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fA
> kM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd
> 4eXqDhIWGh4iJipKTlJWW......... [much more]
>
> When the URL is long, the action is not called in rails. But, if I
> remove the image from the URL, then the action is called.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From codeturkey at comcast.net  Wed Mar  7 10:15:37 2007
From: codeturkey at comcast.net (Steven Hansen)
Date: Wed, 07 Mar 2007 07:15:37 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <45EED719.6040301@comcast.net>

Joe Lester wrote:
> My rails web app (rails 1.2.1) uploads an image from a Java applet by  
> encoding it into the URL. 

Why not use the POST method to upload the image... it can handle a lot 
more data than GET. 

http://en.wikipedia.org/wiki/HTTP#Request_methods


-Steven

From zedshaw at zedshaw.com  Wed Mar  7 13:34:10 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 7 Mar 2007 10:34:10 -0800
Subject: [Mongrel] Long URLs - New to Mongrel
In-Reply-To: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
References: <0E7C5FEB-64EB-4BAF-AA3D-9C3865B79951@sweetwater.com>
Message-ID: <20070307103410.6207043c.zedshaw@zedshaw.com>

On Wed, 7 Mar 2007 08:02:23 -0500
Joe Lester <joe_lester at sweetwater.com> wrote:

> My rails web app (rails 1.2.1) uploads an image from a Java applet by  
> encoding it into the URL. This works fine when I'm using Webrick. I'm  
> trying out Mongrel today, and I'm getting an error in Safari that  
> says ?lost network connection? (NSURLErrorDomain:-1005). I get  
> something similar in Firefox. Is there a way to make Mongrel accept a  
> really long URL like this?
> 
> Thanks. Joe.

Joe, Mongrel enforces limits on the data it accepts in order to prevent
various attacks.  As many other folks mentioned you should probably be
encoding that in a POST rather than GET request.  Just for your
reference, here's the limits that you'll hit:

FIELD_NAME = 256
FIELD_VALUE = 80 * 1024
REQUEST_URI = 1024 * 12
REQUEST_PATH = 1024
QUERY_STRING = 1024 * 10
HEADER = 1024 * (80 + 32)

FIELD_VALUE and HEADER limits are mostly to allow for the insane size
of Cookies.  You're probably hitting the QUERY_STRING limit of 10k or
the REQUEST_URI