From ry at tinyclouds.org  Mon Apr  2 06:34:06 2007
From: ry at tinyclouds.org (Ry Dahl)
Date: Mon, 2 Apr 2007 12:34:06 +0200
Subject: [Mongrel] a new upload progress bar
Message-ID: <21ee31950704020334x28eb96b2t2c6f2458d7823ed9@mail.gmail.com>

I'm modifying techno weenie's progress bar plug-in. Currently it works
by making the browser poll the server, via AJAX, for updates on amount
received. My plug-in provides a handler which will stream updates on
the amount received, thus only one request needs to be made. Also, the
progress can be updated at faster rates since the client doesn't need
to poll. This should reduce loads on both server and client.

It's a work in progress but check it out:
http://four.livejournal.com/747302.html

ry

From blindance at gmail.com  Mon Apr  2 07:43:16 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Mon, 2 Apr 2007 20:43:16 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
Message-ID: <474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>

Thank you,


> This is actually a "cross-platform" issue, between Win32 and WOW64 :-P
> Could you test the attached file?

XPSP2 x64
 this process (PID, name): 2192, proc_info.exe
 parent process (PID, name): 3592, <unknown>
 Couldn't create Snapshot
 parent process by thunk (PID, name): 3592, <unknown>


2003SP1 x64
 this process (PID, name): 420, proc_info.exe
 parent process (PID, name): 648, <unknown>
 Couldn't create Snapshot
 parent process by thunk (PID, name): 648, <unknown>


mmm... I guess nothing is changed from the previous proc_info...

From luislavena at gmail.com  Mon Apr  2 12:48:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 13:48:08 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
Message-ID: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>

On 4/2/07, blindance at gmail.com <blindance at gmail.com> wrote:
> Thank you,
>
>
> > This is actually a "cross-platform" issue, between Win32 and WOW64 :-P
> > Could you test the attached file?
>
> XPSP2 x64
>  this process (PID, name): 2192, proc_info.exe
>  parent process (PID, name): 3592, <unknown>
>  Couldn't create Snapshot
>  parent process by thunk (PID, name): 3592, <unknown>
>
>
> 2003SP1 x64
>  this process (PID, name): 420, proc_info.exe
>  parent process (PID, name): 648, <unknown>
>  Couldn't create Snapshot
>  parent process by thunk (PID, name): 648, <unknown>
>
>
> mmm... I guess nothing is changed from the previous proc_info...

Guess it didn't...

Third round, hope this time we get it right, expected output:

*** CURRENT PROCESS ***
EnumProcessModules (PID, name): 3128      proc_info.exe
Module32First (PID, name): 3128           proc_info.exe
GetProcessImageFileName (PID, name): 3128 \Device\HarddiskVolume5\Programming\So
urces\_sandbox\proc_info.exe

*** PARENT PROCESS ***
EnumProcessModules (PID, name): 4084      cmd.exe
Module32First (PID, name): 4084           cmd.exe
GetProcessImageFileName (PID, name): 4084 \Device\HarddiskVolume2\WINDOWS\system
32\cmd.exe

WinAPI documentation is too confusing about 32-bits process listing
64-bits modules or process... also there is a lot of functions that do
the same from different approaches that aren't compatibles with
previous version of windows.

(i.e. QueryFullProcessImageName is only available in Vista and Windows
Server "Longhorn")...

Maybe I could code some dynamic loading (like psapi in proc_info) to
workaround this case scenario.

Please let me know the results.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_info_3.7z
Type: application/octet-stream
Size: 12719 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070402/ace1f5f3/attachment-0001.obj 

From Daniel.Berger at qwest.com  Mon Apr  2 15:12:01 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 2 Apr 2007 14:12:01 -0500
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>

<snip>
 
> Maybe I could code some dynamic loading (like psapi in 
> proc_info) to workaround this case scenario.
> 
> Please let me know the results.

Are you just trying to get process information? The sys-proctable
package works on MS Windows. I dropped the psapi approach a long time
ago in favor of OLE + WMI. So long as the WMI service is running, it
should work on any Windows platform.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From luislavena at gmail.com  Mon Apr  2 15:25:51 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 16:25:51 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F47@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> <snip>
>
> > Maybe I could code some dynamic loading (like psapi in
> > proc_info) to workaround this case scenario.
> >
> > Please let me know the results.
>
> Are you just trying to get process information? The sys-proctable
> package works on MS Windows. I dropped the psapi approach a long time
> ago in favor of OLE + WMI. So long as the WMI service is running, it
> should work on any Windows platform.
>

Thanks Dan for the information, but OLE + WMI is overkill for the
task. Since I support XP, 2003 and Vista on 32bits platforms, using
psapi way is what I wanted.

The dynamic loading of functions under x64 platforms is though, but
could work around it (also, waiting for my OEM Vista to arrive... damn
postal parcels!)

The funny thing is "So long as the WMI service is running" ;-)

Also, I dropped win32-service support on previous releases for a
native, compiled implementation that don't hook or crash the RubyVM
used by Mongrel. Which worked better, until users start jumping to x64
platforms ;-)

Guess that my platform upgrade will be sooner than expected.

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 Daniel.Berger at qwest.com  Mon Apr  2 18:01:53 2007
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 2 Apr 2007 17:01:53 -0500
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>

> -----Original Message-----
> From: mongrel-users-bounces at rubyforge.org 
> [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
> Sent: Monday, April 02, 2007 1:26 PM
> To: mongrel-users at rubyforge.org
> Subject: Re: [Mongrel] mongrel_service fails to get 
> "service.exe" from ppid?
> 
> 
> On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > <snip>
> >
> > > Maybe I could code some dynamic loading (like psapi in
> > > proc_info) to workaround this case scenario.
> > >
> > > Please let me know the results.
> >
> > Are you just trying to get process information? The sys-proctable 
> > package works on MS Windows. I dropped the psapi approach a 
> long time 
> > ago in favor of OLE + WMI. So long as the WMI service is 
> running, it 
> > should work on any Windows platform.
> >
> 
> Thanks Dan for the information, but OLE + WMI is overkill for 
> the task. Since I support XP, 2003 and Vista on 32bits 
> platforms, using psapi way is what I wanted.

Overkill? It's abstracted away for you:

require 'sys/proctable'
include Sys

ProcTable.ps{ |process| p process.ppid }
 
> The dynamic loading of functions under x64 platforms is 
> though, but could work around it (also, waiting for my OEM 
> Vista to arrive... damn postal parcels!)

With sys-proctable, you needn't worry about such things.

> The funny thing is "So long as the WMI service is running" ;-)

Well, it's enabled by default. So, unless someone goes in and turns it
off, it's running.
 
> Also, I dropped win32-service support on previous releases 
> for a native, compiled implementation that don't hook or 
> crash the RubyVM used by Mongrel. Which worked better, until 
> users start jumping to x64 platforms ;-)

Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
has proven to be annoying.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From luislavena at gmail.com  Mon Apr  2 18:50:43 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 19:50:43 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021550v27bb7094l9c93b553c39fc21c@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > -----Original Message-----
> > From: mongrel-users-bounces at rubyforge.org
> > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Luis Lavena
> > Sent: Monday, April 02, 2007 1:26 PM
> > To: mongrel-users at rubyforge.org
> > Subject: Re: [Mongrel] mongrel_service fails to get
> > "service.exe" from ppid?
> >
> >
> > On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> > > <snip>
> > >
> > > > Maybe I could code some dynamic loading (like psapi in
> > > > proc_info) to workaround this case scenario.
> > > >
> > > > Please let me know the results.
> > >
> > > Are you just trying to get process information? The sys-proctable
> > > package works on MS Windows. I dropped the psapi approach a
> > long time
> > > ago in favor of OLE + WMI. So long as the WMI service is
> > running, it
> > > should work on any Windows platform.
> > >
> >
> > Thanks Dan for the information, but OLE + WMI is overkill for
> > the task. Since I support XP, 2003 and Vista on 32bits
> > platforms, using psapi way is what I wanted.
>
> Overkill? It's abstracted away for you:
>
> require 'sys/proctable'
> include Sys
>
> ProcTable.ps{ |process| p process.ppid }
>

Overkill since I no longer use win32-service nor a ruby process as
service, but a stub native service utility that spawn the ruby process
with mongrel.

>[...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don't hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.
>

As I said previously and a few months back, ruby + green_threads +
sockets + rails + win32 != stable solution.

The most stable and gracefully stoppable I got was using a compiled
service and leave ruby just for mongrel.

-- 
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 luislavena at gmail.com  Mon Apr  2 18:56:00 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Apr 2007 19:56:00 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
References: <71166b3b0704021225v4a794d62rc0792b96a0ecca66@mail.gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB0D0F48@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0704021556l2022387aoa25acf2e4352ef6f@mail.gmail.com>

On 4/2/07, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> [...]
>
> > Also, I dropped win32-service support on previous releases
> > for a native, compiled implementation that don't hook or
> > crash the RubyVM used by Mongrel. Which worked better, until
> > users start jumping to x64 platforms ;-)
>
> Hm, I really need to revisit win32-service. The whole VC 6 vs VC 8 issue
> has proven to be annoying.

I have started using Windows SDK Update for Vista [1] which sport VC8
sp1, Platform SDK headers + MSDN help, using just 500MB of HDD. This
is the same compiler used by Visual Studio, and most important is
*free*

I'm trying to get everything setup and drop VC6 for good sake, even if
I have to recompile every extension available.

Maybe we could talk about this off the list if you're interested?

[1] http://www.microsoft.com/downloads/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en

-- 
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 blindance at gmail.com  Tue Apr  3 06:49:21 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Tue, 3 Apr 2007 19:49:21 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
Message-ID: <474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>

> Maybe I could code some dynamic loading (like psapi in proc_info) to
> workaround this case scenario.
>
> Please let me know the results.

WinXP x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 2020      proc_info.exe
 Module32First (PID, name): 2020           proc_info.exe
 GetProcessImageFileName (PID, name): 2020
\Device\HarddiskVolume1\Documents and
Settings\Administrator\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 2416      <unknown>
 Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 2416
\Device\HarddiskVolume1\WINDOWS\system32\cmd.exe



Win2003 x64
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1856      proc_info.exe
 Module32First (PID, name): 1856           proc_info.exe
 GetProcessImageFileName (PID, name): 1856
\Device\HarddiskVolume2\Documents and
Settings\VMWServ\desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1584      <unknown>
 Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1584
\Device\HarddiskVolume2\WINDOWS\system32\cmd.exe



Woot!

I'm happy if this would help even a little.

From cremes.devlist at mac.com  Tue Apr  3 08:30:16 2007
From: cremes.devlist at mac.com (cremes.devlist at mac.com)
Date: Tue, 3 Apr 2007 07:30:16 -0500
Subject: [Mongrel] [OT] Ragel and FSM tutorials
Message-ID: <D6347FBF-8FF9-4C9C-907D-7371434D39B2@mac.com>

This is off-topic.

I'm hoping someone on this list can point me towards more general  
information on finite state machines, their definition, how to build  
them, determining when to apply them, etc. I read Zed's blog entry  
from way back when covering Ragel [1] but he hasn't followed it up  
and there aren't many pointers to external information.

I've googled around and found a reasonable amount of information on  
Ragel, but I'm not so interested in knowing how to use that  
particular tool as I am in learning about finite state machines *in  
general*.

Thanks to anyone who has good pointers on docs, tutorials or good  
source code examples (any language). I'd also appreciate any  
suggestions on books (college texts or whatever) that cover this  
subject.

cr

From serdar at kilic.net  Tue Apr  3 09:12:13 2007
From: serdar at kilic.net (Serdar Kilic)
Date: Tue, 3 Apr 2007 23:12:13 +1000
Subject: [Mongrel] MediaTemple Image upload
Message-ID: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>

Hi All,
I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel  
on their GridServer. My rails app has an image upload facility  
whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've  
requested an upgrade to the latest version of mongrel but don't  
believe that's going to happen too soon. I'm not getting too much  
information in the log files too pass on, other than what appears to  
be a memory allocation error (my container is 64Mb). Any ideas?

Regards,
Serdar

From craigkuhns at gmail.com  Tue Apr  3 10:17:10 2007
From: craigkuhns at gmail.com (Craig Kuhns)
Date: Tue, 3 Apr 2007 10:17:10 -0400
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
Message-ID: <14adac440704030717t2cae9bf5r6fff2f3a50265259@mail.gmail.com>

>From my understanding its not good practice to use rails for large
file uploads because it locks the thread up.  Maybe look into
integrating merb into your app to handle the file uploads.  I don't
know if that will fix your problem or not, but it will improve your
performance.

Craig

On 4/3/07, Serdar Kilic <serdar at kilic.net> wrote:
> Hi All,
> I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel
> on their GridServer. My rails app has an image upload facility
> whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've
> requested an upgrade to the latest version of mongrel but don't
> believe that's going to happen too soon. I'm not getting too much
> information in the log files too pass on, other than what appears to
> be a memory allocation error (my container is 64Mb). Any ideas?
>
> Regards,
> Serdar
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From zedshaw at zedshaw.com  Tue Apr  3 11:14:01 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 3 Apr 2007 11:14:01 -0400
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
Message-ID: <20070403111401.646f977e.zedshaw@zedshaw.com>

On Tue, 3 Apr 2007 23:12:13 +1000
Serdar Kilic <serdar at kilic.net> wrote:

> Hi All,
> I'm hosting with MediaTemple who are currently using 0.3.3 of mongrel  
> on their GridServer. My rails app has an image upload facility  
> whereby if you upload a large image (e.g. 5Mb) mongrel crashes. I've  
> requested an upgrade to the latest version of mongrel but don't  
> believe that's going to happen too soon. I'm not getting too much  
> information in the log files too pass on, other than what appears to  
> be a memory allocation error (my container is 64Mb). Any ideas?

Mongrel isn't crashing, most likely you have too little RAM and the
linux oomkiller is killing Mongrel off when it gets too big.  Take your
app, put it on a computer with lots of ram, and then try a bunch of
giant uploads to make sure.  Then, if it still works simply go buy more
RAM from MT.

-- 
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 luislavena at gmail.com  Tue Apr  3 12:13:52 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 3 Apr 2007 13:13:52 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
Message-ID: <71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>

On 4/3/07, blindance at gmail.com <blindance at gmail.com> wrote:
> > Maybe I could code some dynamic loading (like psapi in proc_info) to
> > workaround this case scenario.
> >
> > Please let me know the results.
>
> WinXP x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 2020      proc_info.exe
>  Module32First (PID, name): 2020           proc_info.exe
>  GetProcessImageFileName (PID, name): 2020
> \Device\HarddiskVolume1\Documents and
> Settings\Administrator\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 2416      <unknown>
>  Module32First (PID, name): 2416           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 2416
> \Device\HarddiskVolume1\WINDOWS\system32\cmd.exe
>
>
>
> Win2003 x64
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1856      proc_info.exe
>  Module32First (PID, name): 1856           proc_info.exe
>  GetProcessImageFileName (PID, name): 1856
> \Device\HarddiskVolume2\Documents and
> Settings\VMWServ\desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1584      <unknown>
>  Module32First (PID, name): 1584           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1584
> \Device\HarddiskVolume2\WINDOWS\system32\cmd.exe
>
>
>
> Woot!
>
> I'm happy if this would help even a little.


Yeah, I'm happy too!

It seems that ReadProcessMemory (which is called from Module32First
API), fail to get information from 64-bits parent process.

I'll like to know from Vista users that hang on the list about their
results too, since WinAPI is always a pain to get working on different
platforms.

Anyway, based on these results I'll patch ServiceFB and prepare a
pre-release of mongrel_service with logging capabilities too (which is
waiting in my out-box to be commited).

Thanks for your help and feedback.

Later,

-- 
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 mikeisgreat at gmail.com  Tue Apr  3 12:23:43 2007
From: mikeisgreat at gmail.com (Michael Steinfeld)
Date: Tue, 3 Apr 2007 12:23:43 -0400
Subject: [Mongrel] mongrel cluster restart with capistrano fails but
	manually works
Message-ID: <3d5db09e0704030923m563fcbcdiede0e36f668b8c20@mail.gmail.com>

Hi all,

I am out of my head here...

I have a 3 node cluster with 10 mongrels running on each. When I
deploy, I break all the mongrels every time. I have tried just about
everything. I can restart my mongrels without a hitch manually, it's
only when I use cap deploy. Maybe I am missing something here... so if
I can get some help it would be appreciated. The errors are the
typical mongrel pid errors, I can paste them if need be.

I have mongrel_cluster.yml sym linked from
/{current_path}/config/mongrel_cluster.yml to
/etc/mongrel_cluster/mongrel_cluster.yml

cwd: /home/app/current
port: "8000"
address: 127.0.0.1
pid_file: log/mongrel.pid
environment: production
servers: 10



here is a snippet of  my deploy.rb

<snip>

require 'mongrel_cluster/recipes'
require 'capistrano'

# below snipped for brevity
role :web
role :app

...


# restart mongrel with /etc/init.d/mongrel_cluster restart
desc "Restart the web server"
task :restart, :roles => :app do
  begin
    run "sudo /etc/init.d/mongrel_cluster stop"
    run "sleep 5"
    run "sudo /etc/init.d/mongrel_cluster start"
end

...
# couple of tasks to chown some files and directories
desc "Only app servers get this applied to them post-deployment"
task :after_app_deploy, :roles=>:app do
  sudo "chown -PRf foo:foo       #{deploy_to}/current/"
  sudo "chown -PRf foo:foo       #{deploy_to}/releases/"
  sudo "chmod -Rf 755                     #{deploy_to}/releases/"
  sudo "chmod -Rf 750                     #{deploy_to}/current/public/"
end

desc "Apache restarter"
task :kick_apache, :roles=>:web do
  sudo "/usr/local/apache/bin/apachectl restart"
end


Now, mongrel gets restarted even if I don't use the above when I
restart when I run deploy.. but I don't see where I can change that or
if that is in fact causing the problem.

for whatever reason, mongrels never start on 8000 - 8004, but do start
from 8005 - 8009, so I am thinking something in the cap script. I did
migrate recently from lighty+fastcgi to apache+mongrel
and I have 10 mongrels per machine on ports 8000 - 8009. I was
thinking that dispatch was screwing up ports 8000-04 somehow.. (
totally guessing )

I was thinking about writing a task similar to below... but I think it
is overkill.

desc "Kill all the pids in case there are some zombies and remove the
.pid files"
task :before_before_deploy, roles => :app do
  begin
    run "sudo kill -9 `ps -ef | grep mongrel | egrep -v grep | awk
'{print $2}'`"
    run "cd /home/user/app/log && sudo rm -rf *.pid"
  end

task :after_after_deploy, roles => :app do
  begin
    " sudo /etc/init.d/mongrel_cluster start"
  end

</snip>


Hopefully someone can see something that I don't.
Thanks for your time

-- 
-mike

From jjhogue at sbcglobal.net  Tue Apr  3 12:26:13 2007
From: jjhogue at sbcglobal.net (Jim Hogue)
Date: Tue, 3 Apr 2007 12:26:13 -0400
Subject: [Mongrel] [OT] Ragel and FSM tutorials
References: <D6347FBF-8FF9-4C9C-907D-7371434D39B2@mac.com>
Message-ID: <004501c7760c$cc9c02d0$0400a8c0@DEN2>

(Off topic, but just in case others are interested :-).

You should probably take a look at some computer science college level 
theory books.  Look for "Automata Theory", "Turing machines", 
"deterministic finite automation", and "non-deterministic finite 
automation".  The turning machine is the classic example.

I have 2 classic texts on my shelf with good coverage - "Introduction 
to Automata Theory, Languages and Computation" and "The design and 
Analysis of Computer Algorithms" (Aho, Hopcroft, and Ullman authors). 
Note that any text used for a comp sci theory course should have 
coverage of this stuff (I am guessing that the 2 I mentioned are out 
of print since it has been a zillion years since I got my comp sci 
degree :-).  Putting "Hopcroft" in the search pane at Amazon brings up 
a number of texts.

In college we had an implementation of a Turing machine using macros 
in vi.  It was a classic.

I would guess that there are other implementations of Turing machines 
out there.

    - Jim

----- Original Message ----- 
From: <cremes.devlist at mac.com>
To: <mongrel-users at rubyforge.org>
Sent: Tuesday, April 03, 2007 8:30 AM
Subject: [Mongrel] [OT] Ragel and FSM tutorials


> This is off-topic.
>
> I'm hoping someone on this list can point me towards more general
> information on finite state machines, their definition, how to build
> them, determining when to apply them, etc. I read Zed's blog entry
> from way back when covering Ragel [1] but he hasn't followed it up
> and there aren't many pointers to external information.
>
> I've googled around and found a reasonable amount of information on
> Ragel, but I'm not so interested in knowing how to use that
> particular tool as I am in learning about finite state machines *in
> general*.
>
> Thanks to anyone who has good pointers on docs, tutorials or good
> source code examples (any language). I'd also appreciate any
> suggestions on books (college texts or whatever) that cover this
> subject.
>
> cr
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
> 



From subimage at gmail.com  Tue Apr  3 14:05:50 2007
From: subimage at gmail.com (subimage interactive)
Date: Tue, 3 Apr 2007 11:05:50 -0700
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
Message-ID: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>

Yo Zed and everyone else, I'm having a major problem I'm hoping someone can
help with.

I've been running mongrel clusters for a few months with no problems on a
couple of my boxes. They both run Debian...

I recently moved one of my older Rails apps on a FreeBSD 5.5 box to mongrel
as well. Everything runs quickly and wonderfully - when it's running! My
problem is that over time each one of my 5 mongrel processes die. There's
nothing in the mongrel.log telling me why they die. They just die.

My question then is two-fold

1: Why are my mongrel processes dying? Where's the log information?
2: Can these guys be automatically restarted somehow???

I'm on mongrel 1.0.1 and mongrel_cluster 1.0.1.1

HELP! My clients are going apeshit and want to cut my throat :p


--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/f8f32bdb/attachment.html 

From zedshaw at zedshaw.com  Tue Apr  3 15:05:08 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Tue, 3 Apr 2007 15:05:08 -0400
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
Message-ID: <20070403150508.5350bf33.zedshaw@zedshaw.com>

On Tue, 3 Apr 2007 11:05:50 -0700
"subimage interactive" <subimage at gmail.com> wrote:

> Yo Zed and everyone else, I'm having a major problem I'm hoping someone can
> help with.
> 
> I've been running mongrel clusters for a few months with no problems on a
> couple of my boxes. They both run Debian...
> 
> I recently moved one of my older Rails apps on a FreeBSD 5.5 box to mongrel
> as well. Everything runs quickly and wonderfully - when it's running! My
> problem is that over time each one of my 5 mongrel processes die. There's
> nothing in the mongrel.log telling me why they die. They just die.

You'll have to be more specific than that.  "Die" could mean they crash
and the process goes away, or that the process stops responding to
requests.  For the first kind you'll need to turn on core dumps and do
a gdb inspect after.  With the second one you've gotta list out the
various gems you're using and when you find a dead mongrel then attach
to it with strace or gdb to find out where it's blocked.

> My question then is two-fold
> 
> 1: Why are my mongrel processes dying? Where's the log information?
> 2: Can these guys be automatically restarted somehow???

Yes, monit works great, other folks like runit.  There's a bunch of
tutorials for both.

-- 
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 subimage at gmail.com  Tue Apr  3 15:18:01 2007
From: subimage at gmail.com (subimage interactive)
Date: Tue, 3 Apr 2007 12:18:01 -0700
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <20070403150508.5350bf33.zedshaw@zedshaw.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
	<20070403150508.5350bf33.zedshaw@zedshaw.com>
Message-ID: <7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>

> > I recently moved one of my older Rails apps on a FreeBSD 5.5 box to
> mongrel
> > as well. Everything runs quickly and wonderfully - when it's running! My
> > problem is that over time each one of my 5 mongrel processes die.
> There's
> > nothing in the mongrel.log telling me why they die. They just die.
>
> You'll have to be more specific than that.  "Die" could mean they crash
> and the process goes away, or that the process stops responding to
> requests.  For the first kind you'll need to turn on core dumps and do
> a gdb inspect after.  With the second one you've gotta list out the
> various gems you're using and when you find a dead mongrel then attach
> to it with strace or gdb to find out where it's blocked.


Die meaning, dead...process is crashed and gone. How do I turn on core
dumps? This a mongrel switch?


> My question then is two-fold
> >
> > 1: Why are my mongrel processes dying? Where's the log information?
> > 2: Can these guys be automatically restarted somehow???
>
> Yes, monit works great, other folks like runit.  There's a bunch of
> tutorials for both.
>
>
Got a good starting point (besides google) for running either with a
mongrel_cluster?

Thanks for the quick response.

--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/e427a80e/attachment.html 

From jgeiger at gmail.com  Tue Apr  3 16:19:23 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Tue, 3 Apr 2007 15:19:23 -0500
Subject: [Mongrel] Mongrels dying on FreeBSD 5.5-STABLE......why why why?
In-Reply-To: <7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>
References: <7aff9b4c0704031105u4cb25b65occ4bf4fe5f5b0f29@mail.gmail.com>
	<20070403150508.5350bf33.zedshaw@zedshaw.com>
	<7aff9b4c0704031218n4c752f7fw448666f0e7fa677@mail.gmail.com>
Message-ID: <466af3440704031319t63bbf8b4j3ed82d10581015fb@mail.gmail.com>

You should able to do a search for monit and mongrel on this list or
google and get more than enough.

http://www.tildeslash.com/monit/


On 4/3/07, subimage interactive <subimage at gmail.com> wrote:
>
>
> > > I recently moved one of my older Rails apps on a FreeBSD 5.5 box to
> mongrel
> > > as well. Everything runs quickly and wonderfully - when it's running! My
> > > problem is that over time each one of my 5 mongrel processes die.
> There's
> > > nothing in the mongrel.log telling me why they die. They just die.
> >
> > You'll have to be more specific than that.  "Die" could mean they crash
> > and the process goes away, or that the process stops responding to
> > requests.  For the first kind you'll need to turn on core dumps and do
> > a gdb inspect after.  With the second one you've gotta list out the
> > various gems you're using and when you find a dead mongrel then attach
> > to it with strace or gdb to find out where it's blocked.
>
>
> Die meaning, dead...process is crashed and gone. How do I turn on core
> dumps? This a mongrel switch?
>
>
> > > My question then is two-fold
> > >
> > > 1: Why are my mongrel processes dying? Where's the log information?
> > > 2: Can these guys be automatically restarted somehow???
> >
> > Yes, monit works great, other folks like runit.  There's a bunch of
> > tutorials for both.
> >
> >
>
> Got a good starting point (besides google) for running either with a
> mongrel_cluster?
>
> Thanks for the quick response.
>
>
> --------------------
> seth at subimage interactive
> -----
> http://www.subimage.com
> http://sublog.subimage.com
> -----
> http://www.getcashboard.com
> http://dev.subimage.com/projects/substruct
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From bhjackson at gmail.com  Tue Apr  3 16:33:59 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 3 Apr 2007 17:33:59 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I doing
	wrong?
Message-ID: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>

I tried benchmarking the same site behind an NGINX proxy with both
fastcgi and mongrel, and for some reason mongrel is performing pretty
poorly in comparison.

Any idea what I might be doing wrong?

Here's my benchmarks for 1 fcgi:

Server Software:        nginx/0.4.0
Server Hostname:        eship.com.br
Server Port:            80

Document Path:          /
Document Length:        95 bytes

Concurrency Level:      100
Time taken for tests:   10.437 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1000
Total transferred:      366000 bytes
HTML transferred:       95000 bytes
Requests per second:    95.81 [#/sec] (mean)
Time per request:       1043.70 [ms] (mean)
Time per request:       10.44 [ms] (mean, across all concurrent requests)
Transfer rate:          35.07 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:      182   435  294.5    430  3428
Processing:   371   569  296.5    505  2674
Waiting:      189   569  296.5    505  2674
Total:        371  1004  418.8    938  3963




And for 2 mongrels:

Server Software:        nginx/0.4.0
Server Hostname:        eship.com.br
Server Port:            80

Document Path:          /
Document Length:        95 bytes

Concurrency Level:      100
Time taken for tests:   13.041 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1000
Total transferred:      417000 bytes
HTML transferred:       95000 bytes
Requests per second:    76.68 [#/sec] (mean)
Time per request:       1304.10 [ms] (mean)
Time per request:       13.04 [ms] (mean, across all concurrent requests)
Transfer rate:          31.98 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:      175   234  292.9    187  3099
Processing:   204   897  806.4    611  5619
Waiting:      187   897  806.5    611  5619
Total:        365  1132  840.6    842  5804

From snacktime at gmail.com  Tue Apr  3 16:39:28 2007
From: snacktime at gmail.com (snacktime)
Date: Tue, 3 Apr 2007 13:39:28 -0700
Subject: [Mongrel] monit vs mongrel cluster
Message-ID: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>

Is there anything mongrel cluster gives you that monit doesn't?  I'll
be using monit to monitor a number of other services anyways, so it
seems logical to just use it for everything including mongrel.

Chris

From jason at joyent.com  Tue Apr  3 16:39:52 2007
From: jason at joyent.com (Jason A. Hoffman)
Date: Tue, 3 Apr 2007 13:39:52 -0700
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
Message-ID: <6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>

Looking even at your standard deviations, I don't see much of a  
difference between these. What's your SD on the req/sec?

Regards, Jason

On Apr 3, 2007, at 1:33 PM, Benjamin Jackson wrote:

> I tried benchmarking the same site behind an NGINX proxy with both
> fastcgi and mongrel, and for some reason mongrel is performing pretty
> poorly in comparison.
>
> Any idea what I might be doing wrong?
>
> Here's my benchmarks for 1 fcgi:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   10.437 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      366000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    95.81 [#/sec] (mean)
> Time per request:       1043.70 [ms] (mean)
> Time per request:       10.44 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          35.07 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      182   435  294.5    430  3428
> Processing:   371   569  296.5    505  2674
> Waiting:      189   569  296.5    505  2674
> Total:        371  1004  418.8    938  3963
>
>
>
>
> And for 2 mongrels:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   13.041 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      417000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    76.68 [#/sec] (mean)
> Time per request:       1304.10 [ms] (mean)
> Time per request:       13.04 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          31.98 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      175   234  292.9    187  3099
> Processing:   204   897  806.4    611  5619
> Waiting:      187   897  806.5    611  5619
> Total:        365  1132  840.6    842  5804
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 223 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070403/885eef57/attachment.bin 

From ezmobius at gmail.com  Tue Apr  3 17:32:50 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 14:32:50 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
Message-ID: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>


On Apr 3, 2007, at 1:39 PM, snacktime wrote:

> Is there anything mongrel cluster gives you that monit doesn't?  I'll
> be using monit to monitor a number of other services anyways, so it
> seems logical to just use it for everything including mongrel.
>
> Chris
>

Chris-

	WHen you use monit you can still use mongrel_cluster to manage it.  
You need the latest pre release of mongrel_cluster. This is the best  
configuration I've been able to come up with for 64Bit systems. If  
your on 32bit system then you can lower the memory limits by about  
20-30%

check process mongrel_<%= @username %>_5000
   with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5000"
   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 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5001
   with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5001"
   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 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel

check process mongrel_<%= @username %>_5002
   with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
   start program = "/usr/bin/mongrel_rails cluster::start -C /data/<% 
= @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=  
@username %>/current/config/mongrel_cluster.yml --clean --only 5002"
   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 20 restarts within 20 cycles then  
timeout                         # something is wrong, call the sys-admin
   group mongrel


	I wen't for a while using my own scripts to start and stop mongrel  
without using mongrel_cluster. But it works more reliably when I use  
mongrel_cluster and monit together.

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



From njvack at wisc.edu  Tue Apr  3 17:34:09 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Tue, 3 Apr 2007 16:34:09 -0500
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
Message-ID: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>

Are you running these tests cold? You probably want to throw out the  
first bunch of requests (say, 1000) to better simulate real-world  
running conditions.

Also, what's up with the non-2xx responses? Are you benchmarking an  
error page or something?

-Nate

On Apr 3, 2007, at 3:33 PM, Benjamin Jackson wrote:

> I tried benchmarking the same site behind an NGINX proxy with both
> fastcgi and mongrel, and for some reason mongrel is performing pretty
> poorly in comparison.
>
> Any idea what I might be doing wrong?
>
> Here's my benchmarks for 1 fcgi:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   10.437 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      366000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    95.81 [#/sec] (mean)
> Time per request:       1043.70 [ms] (mean)
> Time per request:       10.44 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          35.07 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      182   435  294.5    430  3428
> Processing:   371   569  296.5    505  2674
> Waiting:      189   569  296.5    505  2674
> Total:        371  1004  418.8    938  3963
>
>
>
>
> And for 2 mongrels:
>
> Server Software:        nginx/0.4.0
> Server Hostname:        eship.com.br
> Server Port:            80
>
> Document Path:          /
> Document Length:        95 bytes
>
> Concurrency Level:      100
> Time taken for tests:   13.041 seconds
> Complete requests:      1000
> Failed requests:        0
> Broken pipe errors:     0
> Non-2xx responses:      1000
> Total transferred:      417000 bytes
> HTML transferred:       95000 bytes
> Requests per second:    76.68 [#/sec] (mean)
> Time per request:       1304.10 [ms] (mean)
> Time per request:       13.04 [ms] (mean, across all concurrent  
> requests)
> Transfer rate:          31.98 [Kbytes/sec] received
>
> Connnection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:      175   234  292.9    187  3099
> Processing:   204   897  806.4    611  5619
> Waiting:      187   897  806.5    611  5619
> Total:        365  1132  840.6    842  5804
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


From kevwil at gmail.com  Tue Apr  3 17:55:04 2007
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 3 Apr 2007 15:55:04 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
Message-ID: <683a886f0704031455k3d7c2195x47ff65a44651b98e@mail.gmail.com>

I do pretty much the same thing with monit, except I don't use
mongrel_cluster. Because monit needs to handle each instance of
mongrel separately, I didn't see the point in using a clustering tool
to handle single instances. It's a minor difference, really -
specifying the mongrel_rails options in the monitrc file vs. the
config/mongrel_cluster.yml file. Either way, I use monit to restart a
mongrel cluster (or "group" as monit calls it).

I'd say monit offers _more_ than mongrel_cluster, but I'm no expert.


On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>
> > Is there anything mongrel cluster gives you that monit doesn't?  I'll
> > be using monit to monitor a number of other services anyways, so it
> > seems logical to just use it for everything including mongrel.
> >
> > Chris
> >
>
> Chris-
>
>         WHen you use monit you can still use mongrel_cluster to manage it.
> You need the latest pre release of mongrel_cluster. This is the best
> configuration I've been able to come up with for 64Bit systems. If
> your on 32bit system then you can lower the memory limits by about
> 20-30%
>
> check process mongrel_<%= @username %>_5000
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5001
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5002
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
>
>         I wen't for a while using my own scripts to start and stop mongrel
> without using mongrel_cluster. But it works more reliably when I use
> mongrel_cluster and monit together.
>
> Cheers-
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Cheers,

Kevin Williams
http://www.almostserio.us/

"Any sufficiently advanced technology is indistinguishable from
Magic." - Arthur C. Clarke

From kevwil at gmail.com  Tue Apr  3 17:58:36 2007
From: kevwil at gmail.com (Kevin Williams)
Date: Tue, 3 Apr 2007 15:58:36 -0600
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
Message-ID: <683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>

You might try a more current version of Nginx and see if the proxying
performance has improved compared to the FastCGI support. You're using
a fairly old version.

http://nginx.net/CHANGES


On 4/3/07, Nathan Vack <njvack at wisc.edu> wrote:
> Are you running these tests cold? You probably want to throw out the
> first bunch of requests (say, 1000) to better simulate real-world
> running conditions.
>
> Also, what's up with the non-2xx responses? Are you benchmarking an
> error page or something?
>
> -Nate
>
> On Apr 3, 2007, at 3:33 PM, Benjamin Jackson wrote:
>
> > I tried benchmarking the same site behind an NGINX proxy with both
> > fastcgi and mongrel, and for some reason mongrel is performing pretty
> > poorly in comparison.
> >
> > Any idea what I might be doing wrong?
> >
> > Here's my benchmarks for 1 fcgi:
> >
> > Server Software:        nginx/0.4.0
> > Server Hostname:        eship.com.br
> > Server Port:            80
> >
> > Document Path:          /
> > Document Length:        95 bytes
> >
> > Concurrency Level:      100
> > Time taken for tests:   10.437 seconds
> > Complete requests:      1000
> > Failed requests:        0
> > Broken pipe errors:     0
> > Non-2xx responses:      1000
> > Total transferred:      366000 bytes
> > HTML transferred:       95000 bytes
> > Requests per second:    95.81 [#/sec] (mean)
> > Time per request:       1043.70 [ms] (mean)
> > Time per request:       10.44 [ms] (mean, across all concurrent
> > requests)
> > Transfer rate:          35.07 [Kbytes/sec] received
> >
> > Connnection Times (ms)
> >               min  mean[+/-sd] median   max
> > Connect:      182   435  294.5    430  3428
> > Processing:   371   569  296.5    505  2674
> > Waiting:      189   569  296.5    505  2674
> > Total:        371  1004  418.8    938  3963
> >
> >
> >
> >
> > And for 2 mongrels:
> >
> > Server Software:        nginx/0.4.0
> > Server Hostname:        eship.com.br
> > Server Port:            80
> >
> > Document Path:          /
> > Document Length:        95 bytes
> >
> > Concurrency Level:      100
> > Time taken for tests:   13.041 seconds
> > Complete requests:      1000
> > Failed requests:        0
> > Broken pipe errors:     0
> > Non-2xx responses:      1000
> > Total transferred:      417000 bytes
> > HTML transferred:       95000 bytes
> > Requests per second:    76.68 [#/sec] (mean)
> > Time per request:       1304.10 [ms] (mean)
> > Time per request:       13.04 [ms] (mean, across all concurrent
> > requests)
> > Transfer rate:          31.98 [Kbytes/sec] received
> >
> > Connnection Times (ms)
> >               min  mean[+/-sd] median   max
> > Connect:      175   234  292.9    187  3099
> > Processing:   204   897  806.4    611  5619
> > Waiting:      187   897  806.5    611  5619
> > Total:        365  1132  840.6    842  5804
> > _______________________________________________
> > 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
>


-- 
Cheers,

Kevin Williams
http://www.almostserio.us/

"Any sufficiently advanced technology is indistinguishable from
Magic." - Arthur C. Clarke

From snacktime at gmail.com  Tue Apr  3 18:00:00 2007
From: snacktime at gmail.com (snacktime)
Date: Tue, 3 Apr 2007 15:00:00 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
Message-ID: <1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>

Makes sense that mongrel_cluster would handle a lot of edge cases
better then monit.  Is it mainly the pid file handling that has been
the main issue so far?

Have you tried daemontools?  Seems to me like it would be more
reliable since you wouldn't have to deal with pid files and
backgrounding mongrel.

Chris

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>
> > Is there anything mongrel cluster gives you that monit doesn't?  I'll
> > be using monit to monitor a number of other services anyways, so it
> > seems logical to just use it for everything including mongrel.
> >
> > Chris
> >
>
> Chris-
>
>         WHen you use monit you can still use mongrel_cluster to manage it.
> You need the latest pre release of mongrel_cluster. This is the best
> configuration I've been able to come up with for 64Bit systems. If
> your on 32bit system then you can lower the memory limits by about
> 20-30%
>
> check process mongrel_<%= @username %>_5000
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5001
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
> check process mongrel_<%= @username %>_5002
>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> = @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>    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 20 restarts within 20 cycles then
> timeout                         # something is wrong, call the sys-admin
>    group mongrel
>
>
>         I wen't for a while using my own scripts to start and stop mongrel
> without using mongrel_cluster. But it works more reliably when I use
> mongrel_cluster and monit together.
>
> Cheers-
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From bhjackson at gmail.com  Tue Apr  3 18:02:46 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Tue, 3 Apr 2007 19:02:46 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<6D595D32-7B83-49D7-9BCC-84F4E8C48E45@joyent.com>
Message-ID: <cb03bffe0704031502l2459742raa4e569c2df03698@mail.gmail.com>

> Looking even at your standard deviations, I don't see much of a
> difference between these. What's your SD on the req/sec?

Thanks for the heads-up Jason.

ab doesn't have a SD on the req/sec AFAIK, tried doing (I think)
equivalent benchmarks with httperf, this time from the server, and I
got the following results. It seems like FastCGI is marginally faster
than Mongrel for my site when both are run with 2 dispatchers.

Does this sound like an accurate test, or did I miss something
essential in the benchmarking process? Thanks,

Ben

---------------------------------------------------

FastCGI (1 proc):

$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 7

Total: connections 1000 requests 1000 replies 1000 test-duration 16.141 s

Connection rate: 62.0 conn/s (16.1 ms/conn, <=257 concurrent connections)
Connection time [ms]: min 10.2 avg 1741.3 max 9040.8 median 1614.5 stddev 1737.0
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 62.0 req/s (16.1 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 48.2 avg 65.7 max 75.0 stddev 15.1 (3 samples)
Reply time [ms]: response 1741.3 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.31 system 13.72 (user 8.1% system 85.0% total 93.1%)
Net I/O: 28.0 KB/s (0.2*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

---------------------------------------------------

FastCGI (2 procs):

$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 8

Total: connections 1000 requests 1000 replies 1000 test-duration 11.993 s

Connection rate: 83.4 conn/s (12.0 ms/conn, <=169 concurrent connections)
Connection time [ms]: min 10.7 avg 837.5 max 2047.6 median 831.5 stddev 662.5
Connection time [ms]: connect 0.3
Connection length [replies/conn]: 1.000

Request rate: 83.4 req/s (12.0 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 82.4 avg 83.8 max 85.2 stddev 2.0 (2 samples)
Reply time [ms]: response 837.2 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.23 system 8.75 (user 10.3% system 73.0% total 83.2%)
Net I/O: 37.6 KB/s (0.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

---------------------------------------------------

Mongrel:


$ httperf --server=eship.com.br --rate=100 --num-conns=1000
httperf --client=0/1 --server=eship.com.br --port=80 --uri=/
--rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000
--num-calls=1
Maximum connect burst length: 4

Total: connections 1000 requests 1000 replies 1000 test-duration 13.000 s

Connection rate: 76.9 conn/s (13.0 ms/conn, <=212 concurrent connections)
Connection time [ms]: min 19.5 avg 1117.1 max 4115.2 median 1036.5 stddev 936.0
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 76.9 req/s (13.0 ms/req)
Request size [B]: 63.0

Reply rate [replies/s]: min 74.4 avg 78.9 max 83.4 stddev 6.4 (2 samples)
Reply time [ms]: response 1117.1 transfer 0.0
Reply size [B]: header 304.0 content 95.0 footer 2.0 (total 401.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0

CPU time [s]: user 1.02 system 11.22 (user 7.8% system 86.3% total 94.2%)
Net I/O: 34.7 KB/s (0.3*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

From nclark at mosso.com  Tue Apr  3 17:52:59 2007
From: nclark at mosso.com (Nathan Clark)
Date: Tue, 3 Apr 2007 16:52:59 -0500
Subject: [Mongrel] are memory limits on mongrel possible?
Message-ID: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>

Is there any documentation I can look at that might talk about how to  
put
memory limits on mongrel? For instants, I might want to limit mongrel to
100 megs of ram.  I know that I can monitor mongrel with monit and  
restart it
automatically if it becomes a ram piggy. 

From ezmobius at gmail.com  Tue Apr  3 18:28:06 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 15:28:06 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
Message-ID: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>


	Yes mongrel_cluster handles the pid files. Also it does a better job  
of stopping mongrels. The problem I had when I used monit and  
mongrel_rails without mongrel_cluster was that if a mongrel used too  
much memory monit woudl not be able to stop it sometimes and so  
execution woudl fail and timeout.

	Using mongrel_clutser avoids this problem completely. Trust me I've  
tried it all different ways. I did monit without mongrel_cluster for  
a about a full month on close to 200 servers and then switched them  
all to monit and mongrel_cluster and get much better results.

-Ezra

On Apr 3, 2007, at 3:00 PM, snacktime wrote:

> Makes sense that mongrel_cluster would handle a lot of edge cases
> better then monit.  Is it mainly the pid file handling that has been
> the main issue so far?
>
> Have you tried daemontools?  Seems to me like it would be more
> reliable since you wouldn't have to deal with pid files and
> backgrounding mongrel.
>
> Chris
>
> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>>
>> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
>>
>>> Is there anything mongrel cluster gives you that monit doesn't?   
>>> I'll
>>> be using monit to monitor a number of other services anyways, so it
>>> seems logical to just use it for everything including mongrel.
>>>
>>> Chris
>>>
>>
>> Chris-
>>
>>         WHen you use monit you can still use mongrel_cluster to  
>> manage it.
>> You need the latest pre release of mongrel_cluster. This is the best
>> configuration I've been able to come up with for 64Bit systems. If
>> your on 32bit system then you can lower the memory limits by about
>> 20-30%
>>
>> check process mongrel_<%= @username %>_5000
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5000"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
>>    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 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>> check process mongrel_<%= @username %>_5001
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5001"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
>>    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 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>> check process mongrel_<%= @username %>_5002
>>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
>>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
>> = @username %>/current/config/mongrel_cluster.yml --clean --only  
>> 5002"
>>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
>> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
>>    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 20 restarts within 20 cycles then
>> timeout                         # something is wrong, call the sys- 
>> admin
>>    group mongrel
>>
>>
>>         I wen't for a while using my own scripts to start and stop  
>> mongrel
>> without using mongrel_cluster. But it works more reliably when I use
>> mongrel_cluster and monit together.
>>
>> Cheers-
>> -- Ezra Zygmuntowicz
>> -- Lead Rails Evangelist
>> -- ez at engineyard.com
>> -- Engine Yard, Serious Rails Hosting
>> -- (866) 518-YARD (9273)
>>
>>
>> _______________________________________________
>> 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
>

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



From zackchandler at gmail.com  Tue Apr  3 19:19:39 2007
From: zackchandler at gmail.com (Zack Chandler)
Date: Tue, 3 Apr 2007 16:19:39 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
Message-ID: <33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>

Ezra,

The --clean option is only available in 1.0.1.1 beta I believe?  Are
you finding it stable enough for production environments (EY)?

I've been bitten by orphaned pids many times - I'm looking forward to
putting this into production...

--
Zack Chandler
http://depixelate.com

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
>         Yes mongrel_cluster handles the pid files. Also it does a better job
> of stopping mongrels. The problem I had when I used monit and
> mongrel_rails without mongrel_cluster was that if a mongrel used too
> much memory monit woudl not be able to stop it sometimes and so
> execution woudl fail and timeout.
>
>         Using mongrel_clutser avoids this problem completely. Trust me I've
> tried it all different ways. I did monit without mongrel_cluster for
> a about a full month on close to 200 servers and then switched them
> all to monit and mongrel_cluster and get much better results.
>
> -Ezra
>
> On Apr 3, 2007, at 3:00 PM, snacktime wrote:
>
> > Makes sense that mongrel_cluster would handle a lot of edge cases
> > better then monit.  Is it mainly the pid file handling that has been
> > the main issue so far?
> >
> > Have you tried daemontools?  Seems to me like it would be more
> > reliable since you wouldn't have to deal with pid files and
> > backgrounding mongrel.
> >
> > Chris
> >
> > On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> >>
> >> On Apr 3, 2007, at 1:39 PM, snacktime wrote:
> >>
> >>> Is there anything mongrel cluster gives you that monit doesn't?
> >>> I'll
> >>> be using monit to monitor a number of other services anyways, so it
> >>> seems logical to just use it for everything including mongrel.
> >>>
> >>> Chris
> >>>
> >>
> >> Chris-
> >>
> >>         WHen you use monit you can still use mongrel_cluster to
> >> manage it.
> >> You need the latest pre release of mongrel_cluster. This is the best
> >> configuration I've been able to come up with for 64Bit systems. If
> >> your on 32bit system then you can lower the memory limits by about
> >> 20-30%
> >>
> >> check process mongrel_<%= @username %>_5000
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5000.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5000"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5000"
> >>    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 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >> check process mongrel_<%= @username %>_5001
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5001.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5001"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5001"
> >>    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 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >> check process mongrel_<%= @username %>_5002
> >>    with pidfile /data/<%= @username %>/shared/log/mongrel.5002.pid
> >>    start program = "/usr/bin/mongrel_rails cluster::start -C /data/<%
> >> = @username %>/current/config/mongrel_cluster.yml --clean --only
> >> 5002"
> >>    stop program = "/usr/bin/mongrel_rails cluster::stop -C /data/<%=
> >> @username %>/current/config/mongrel_cluster.yml --clean --only 5002"
> >>    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 20 restarts within 20 cycles then
> >> timeout                         # something is wrong, call the sys-
> >> admin
> >>    group mongrel
> >>
> >>
> >>         I wen't for a while using my own scripts to start and stop
> >> mongrel
> >> without using mongrel_cluster. But it works more reliably when I use
> >> mongrel_cluster and monit together.
> >>
> >> Cheers-
> >> -- Ezra Zygmuntowicz
> >> -- Lead Rails Evangelist
> >> -- ez at engineyard.com
> >> -- Engine Yard, Serious Rails Hosting
> >> -- (866) 518-YARD (9273)
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From alexey.verkhovsky at gmail.com  Tue Apr  3 19:32:39 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 3 Apr 2007 17:32:39 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
Message-ID: <3945c4270704031632v737dba34veafb9ca4a17fbfa2@mail.gmail.com>

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> mongrel_cluster handles the pid files. Also it does a better job
> of stopping mongrels.

Is there some fundamental reason why Mongrel itself cannot handle
these issues well, or does it just need more work in this area?

Alex

From ezmobius at gmail.com  Tue Apr  3 19:44:53 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 3 Apr 2007 16:44:53 -0700
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
Message-ID: <8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>


On Apr 3, 2007, at 4:19 PM, Zack Chandler wrote:

> Ezra,
>
> The --clean option is only available in 1.0.1.1 beta I believe?  Are
> you finding it stable enough for production environments (EY)?
>
> I've been bitten by orphaned pids many times - I'm looking forward to
> putting this into production...
>

Zack-

	Yes the prerelease is production worthy on linux, it still may have  
an issue on FreeBSD. If you are on linux then I highly recommend the  
upgrade. It is running fine on hundreds of servers no and works much  
better then any other way I've had this stuff setup.


On Apr 3, 2007, at 4:32 PM, Alexey Verkhovsky wrote:
> On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> mongrel_cluster handles the pid files. Also it does a better job
>> of stopping mongrels.
>
> Is there some fundamental reason why Mongrel itself cannot handle
> these issues well, or does it just need more work in this area?
>
> Alex

	The reason it's not in mongrel is because bradley made the  
mongrel_cluster gem and so Zed saw no reason to add the same stuff in  
mongrel.

	I have asked for a --clean option for the mongel_rails command that  
would cleanup PID"s but I haven't had time to make a patch,  
especially since mongrel_cluster does a great job managing this stuff.


Cheers-

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



From skilic at gmail.com  Tue Apr  3 21:48:56 2007
From: skilic at gmail.com (=?ISO-8859-9?Q?Serdar_K=FDl=FD=E7?=)
Date: Wed, 4 Apr 2007 11:48:56 +1000
Subject: [Mongrel] MediaTemple Image upload
In-Reply-To: <20070403111401.646f977e.zedshaw@zedshaw.com>
References: <D4B5F167-236E-4F61-B102-CD03B27EC59D@kilic.net>
	<20070403111401.646f977e.zedshaw@zedshaw.com>
Message-ID: <9bff27860704031848r487ecbe2x66b51a99929dd15@mail.gmail.com>

Thanks Guys for the thoughts and ideas - I'll have a look at merb as Craig
suggested as I'm currently running the default setup of 64mb for rails (only
1 app running) and if a single file upload is causing me to run out of
memory then that is troublesome. FWIW, I replaced my own file upload code
with that of recipe 57 if you have the Rails Recipe book, but the issue is
there as well, so it possibly could be a rails related issue.


On 04/04/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
>
> Mongrel isn't crashing, most likely you have too little RAM and the
> linux oomkiller is killing Mongrel off when it gets too big.  Take your
> app, put it on a computer with lots of ram, and then try a bunch of
> giant uploads to make sure.  Then, if it still works simply go buy more
> RAM from MT.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
>
> --
> Cheers,
> Serdar K?l??
> http://weblog.kilic.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070404/902c89d0/attachment-0001.html 

From wayneeseguin at gmail.com  Tue Apr  3 21:52:36 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 3 Apr 2007 21:52:36 -0400
Subject: [Mongrel] are memory limits on mongrel possible?
In-Reply-To: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
References: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
Message-ID: <6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>

Nathan,

Monit is what you are looking for.

http://www.tildeslash.com/monit/

On Apr 03, 2007, at 17:52 , Nathan Clark wrote:

> Is there any documentation I can look at that might talk about how to
> put
> memory limits on mongrel? For instants, I might want to limit  
> mongrel to
> 100 megs of ram.  I know that I can monitor mongrel with monit and
> restart it
> automatically if it becomes a ram piggy.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From pete at nextengine.com  Wed Apr  4 08:43:54 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 05:43:54 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
Message-ID: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>

Hi guys,

I've been running mongrel for a while now with Ruby 1.8.4, and last  
week upgraded to 1.8.6.

Since upgrading, each morning when I wake up there's a big problem:

1. Accessing the site returns a "500 Internal Server Error"
2. All the mongrel_rails processes are still running, but none of  
them are active (when I run top)
3. Lighttpd and pound are still running nicely
4. There's plenty of free RAM
5. There's plenty of free HD
6. When I restart mongrel, it all starts working again

I haven't seen anything like this before.  Does this sound familiar  
to anyone?

Thanks for the help,
Pete

From eden at mojiti.com  Wed Apr  4 09:01:48 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 4 Apr 2007 18:31:48 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>

Standard questions come to mind:
 - What do your logs say?
 - Are you running anything semi-dangerous like rmagick or older
versions of acts_as_ferret?
 - Are you using Ruby based log rotation?

BTW, maybe we could put up solutions to common issues into a page on
mongrel.rubyforge.org? I don't see one on
http://mongrel.rubyforge.org/docs/index.html...

On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Hi guys,
>
> I've been running mongrel for a while now with Ruby 1.8.4, and last
> week upgraded to 1.8.6.
>
> Since upgrading, each morning when I wake up there's a big problem:
>
> 1. Accessing the site returns a "500 Internal Server Error"
> 2. All the mongrel_rails processes are still running, but none of
> them are active (when I run top)
> 3. Lighttpd and pound are still running nicely
> 4. There's plenty of free RAM
> 5. There's plenty of free HD
> 6. When I restart mongrel, it all starts working again
>
> I haven't seen anything like this before.  Does this sound familiar
> to anyone?
>
> Thanks for the help,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Wed Apr  4 09:15:06 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 06:15:06 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
Message-ID: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>

Hi Eden,

I agree: a common issues page is a great idea.  Unfortunately, this  
issue doesn't seem to be one of the usual suspects.

1. The logs just have normal chatter for my app ... nothing unusual
2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,  
since that's when ti started dying.
3. I'm not using log rotation, but the files aren't that big after a  
day.. and there's plenty of free space on disk

Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?

Thanks,
Pete



On Apr 4, 2007, at 6:01 AM, Eden Li wrote:

> Standard questions come to mind:
>  - What do your logs say?
>  - Are you running anything semi-dangerous like rmagick or older
> versions of acts_as_ferret?
>  - Are you using Ruby based log rotation?
>
> BTW, maybe we could put up solutions to common issues into a page on
> mongrel.rubyforge.org? I don't see one on
> http://mongrel.rubyforge.org/docs/index.html...
>
> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>>
>> Since upgrading, each morning when I wake up there's a big problem:
>>
>> 1. Accessing the site returns a "500 Internal Server Error"
>> 2. All the mongrel_rails processes are still running, but none of
>> them are active (when I run top)
>> 3. Lighttpd and pound are still running nicely
>> 4. There's plenty of free RAM
>> 5. There's plenty of free HD
>> 6. When I restart mongrel, it all starts working again
>>
>> I haven't seen anything like this before.  Does this sound familiar
>> to anyone?
>>
>> Thanks for the help,
>> Pete
>> _______________________________________________
>> 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 jackc at hylesanderson.edu  Wed Apr  4 09:50:03 2007
From: jackc at hylesanderson.edu (Jack Christensen)
Date: Wed, 04 Apr 2007 08:50:03 -0500
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
Message-ID: <4613AD0B.7090308@hylesanderson.edu>

Pete DeLaurentis wrote:
>
> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
>   
Yes. In fact, my problems with mongrels dying went away when I went to 
ruby 1.8.6. Of course, I changed a number of other things at the same 
time so I can't say conclusively that the ruby upgrade was the solution. 
But I haven't had any mongrels die since I deployed my new setup last 5 
days ago, and prior to that I was having a mongrel die (as in crash not 
just stop responding) every few hours or so.

-- 
Jack Christensen
jackc at hylesanderson.edu


From eden at mojiti.com  Wed Apr  4 10:11:23 2007
From: eden at mojiti.com (Eden Li)
Date: Wed, 4 Apr 2007 19:41:23 +0530
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
Message-ID: <1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>

Which version of rails are you using?  Version prior to 1.2.3 have a
few issues...  Also, what version of mongrel are you running?

On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Hi Eden,
>
> I agree: a common issues page is a great idea.  Unfortunately, this
> issue doesn't seem to be one of the usual suspects.
>
> 1. The logs just have normal chatter for my app ... nothing unusual
> 2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,
> since that's when ti started dying.
> 3. I'm not using log rotation, but the files aren't that big after a
> day.. and there's plenty of free space on disk
>
> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
>
> Thanks,
> Pete
>
>
>
> On Apr 4, 2007, at 6:01 AM, Eden Li wrote:
>
> > Standard questions come to mind:
> >  - What do your logs say?
> >  - Are you running anything semi-dangerous like rmagick or older
> > versions of acts_as_ferret?
> >  - Are you using Ruby based log rotation?
> >
> > BTW, maybe we could put up solutions to common issues into a page on
> > mongrel.rubyforge.org? I don't see one on
> > http://mongrel.rubyforge.org/docs/index.html...
> >
> > On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> >> Hi guys,
> >>
> >> I've been running mongrel for a while now with Ruby 1.8.4, and last
> >> week upgraded to 1.8.6.
> >>
> >> Since upgrading, each morning when I wake up there's a big problem:
> >>
> >> 1. Accessing the site returns a "500 Internal Server Error"
> >> 2. All the mongrel_rails processes are still running, but none of
> >> them are active (when I run top)
> >> 3. Lighttpd and pound are still running nicely
> >> 4. There's plenty of free RAM
> >> 5. There's plenty of free HD
> >> 6. When I restart mongrel, it all starts working again
> >>
> >> I haven't seen anything like this before.  Does this sound familiar
> >> to anyone?
> >>
> >> Thanks for the help,
> >> Pete
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From pete at nextengine.com  Wed Apr  4 10:27:27 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 07:27:27 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<1dd361e10704040601k2ffae263wc13534f610690479@mail.gmail.com>
	<0D25E365-0871-4C21-9389-DC899003A0F8@nextengine.com>
	<1dd361e10704040711o3a22d282iac0064b51cdc6f85@mail.gmail.com>
Message-ID: <2875AC20-A690-4ED0-BFFC-C304E4A4F72B@nextengine.com>

Hi Eden,

I'm running mongrel1.0.1, mongrel cluster 0.2.1, rails 1.2.3, and  
fastthread 1.0.

I just cleaned up all old gems (since I had some back versions) and  
re-updated all of these gems just to be sure.  Tomorrow morning, I'll  
get to see if this helped :-)

-Pete

On Apr 4, 2007, at 7:11 AM, Eden Li wrote:

> Which version of rails are you using?  Version prior to 1.2.3 have a
> few issues...  Also, what version of mongrel are you running?
>
> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>> Hi Eden,
>>
>> I agree: a common issues page is a great idea.  Unfortunately, this
>> issue doesn't seem to be one of the usual suspects.
>>
>> 1. The logs just have normal chatter for my app ... nothing unusual
>> 2. No rmagick or ferret, but I believe it is related to Ruby 1.8.6,
>> since that's when ti started dying.
>> 3. I'm not using log rotation, but the files aren't that big after a
>> day.. and there's plenty of free space on disk
>>
>> Here's a question: Is anyone running ruby1.8.6 succesfully with  
>> mongrel?
>>
>> Thanks,
>> Pete
>>
>>
>>
>> On Apr 4, 2007, at 6:01 AM, Eden Li wrote:
>>
>>> Standard questions come to mind:
>>>  - What do your logs say?
>>>  - Are you running anything semi-dangerous like rmagick or older
>>> versions of acts_as_ferret?
>>>  - Are you using Ruby based log rotation?
>>>
>>> BTW, maybe we could put up solutions to common issues into a page on
>>> mongrel.rubyforge.org? I don't see one on
>>> http://mongrel.rubyforge.org/docs/index.html...
>>>
>>> On 4/4/07, Pete DeLaurentis <pete at nextengine.com> wrote:
>>>> Hi guys,
>>>>
>>>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>>>> week upgraded to 1.8.6.
>>>>
>>>> Since upgrading, each morning when I wake up there's a big problem:
>>>>
>>>> 1. Accessing the site returns a "500 Internal Server Error"
>>>> 2. All the mongrel_rails processes are still running, but none of
>>>> them are active (when I run top)
>>>> 3. Lighttpd and pound are still running nicely
>>>> 4. There's plenty of free RAM
>>>> 5. There's plenty of free HD
>>>> 6. When I restart mongrel, it all starts working again
>>>>
>>>> I haven't seen anything like this before.  Does this sound familiar
>>>> to anyone?
>>>>
>>>> Thanks for the help,
>>>> Pete
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 zedshaw at zedshaw.com  Wed Apr  4 10:37:37 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Wed, 4 Apr 2007 10:37:37 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>

On Wed, 4 Apr 2007 05:43:54 -0700
Pete DeLaurentis <pete at nextengine.com> wrote:

> Hi guys,
> 
> I've been running mongrel for a while now with Ruby 1.8.4, and last  
> week upgraded to 1.8.6.

First, NEVER upgrade a production server to new versions before you
test the living hell out of it.  This always leads to disaster.

Second, I haven't tested Mongrel on 1.8.6 and there's apparently a
small bug in the new thread implementation that's included.  You'll
want to try out fastthread very latest even if you're running 1.8.6.

Third, whenever you do an upgrade you have to recompile ALL of your
gems.  Every last one.  No matter what.  Best way to do this is
uninstall all of your gems then reinstall the ones you need.  It's good
spring cleaning, but it also makes sure that the compiled extensions
work with the new ruby interpreter.

Lastly, I only deploy 1.8.5 with fastthread, not 1.8.6.  I'm sure
there's bugs lurking in 1.8.6 that haven't been tested out on both
Rails and Mongrel.

Let me know what you find.

-- 
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 mzukowski at urbacon.net  Wed Apr  4 10:54:41 2007
From: mzukowski at urbacon.net (Matt Zukowski)
Date: Wed, 04 Apr 2007 10:54:41 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
Message-ID: <4613BC31.5060803@urbacon.net>

Are you sure this isn't being caused by something unrelated to mongrel
or ruby 1.8.6? We were having a similar problem a while ago and traced
it down mysql closing its connection after 8 hours of inactivity
(ActiveRecord, somewhat stupidly, does not attempt to reconnect the
closed connection).

Pete DeLaurentis wrote:
> Hi guys,
> 
> I've been running mongrel for a while now with Ruby 1.8.4, and last  
> week upgraded to 1.8.6.
> 
> Since upgrading, each morning when I wake up there's a big problem:
> 
> 1. Accessing the site returns a "500 Internal Server Error"
> 2. All the mongrel_rails processes are still running, but none of  
> them are active (when I run top)
> 3. Lighttpd and pound are still running nicely
> 4. There's plenty of free RAM
> 5. There's plenty of free HD
> 6. When I restart mongrel, it all starts working again
> 
> I haven't seen anything like this before.  Does this sound familiar  
> to anyone?
> 
> Thanks for the help,
> Pete
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users



This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.



From pete at nextengine.com  Wed Apr  4 11:27:56 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 08:27:56 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<20070404103737.81c8e0a9.zedshaw@zedshaw.com>
Message-ID: <4B2F7C8A-C16D-4447-982F-BD0FB0892B56@nextengine.com>

Thanks for the tips Zed, I will uninstall + reinstall all of the  
gems.  There is also a new version of fastthread, which I just  
installed.  In the words of the author:

"Well, just when I thought I was done with fastthread, it turns out  
that the version of fastthread merged into Ruby 1.8.6?s thread  
library had a couple serious bugs. So, here?s a new version of  
fastthread which can serve as a hotfix until the next Ruby release."
- MenTaLguY, http://moonbase.rydia.net/

We made the switch to 1.8.6 for the reputed 10% speed boost.  We're  
using it on our in-house server that runs our beta app, and we're not  
upgrading the customer servers until this is stable.

Thanks for the help,
Pete




On Apr 4, 2007, at 7:37 AM, Zed A. Shaw wrote:

> On Wed, 4 Apr 2007 05:43:54 -0700
> Pete DeLaurentis <pete at nextengine.com> wrote:
>
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>
> First, NEVER upgrade a production server to new versions before you
> test the living hell out of it.  This always leads to disaster.
>
> Second, I haven't tested Mongrel on 1.8.6 and there's apparently a
> small bug in the new thread implementation that's included.  You'll
> want to try out fastthread very latest even if you're running 1.8.6.
>
> Third, whenever you do an upgrade you have to recompile ALL of your
> gems.  Every last one.  No matter what.  Best way to do this is
> uninstall all of your gems then reinstall the ones you need.  It's  
> good
> spring cleaning, but it also makes sure that the compiled extensions
> work with the new ruby interpreter.
>
> Lastly, I only deploy 1.8.5 with fastthread, not 1.8.6.  I'm sure
> there's bugs lurking in 1.8.6 that haven't been tested out on both
> Rails and Mongrel.
>
> Let me know what you find.
>
> -- 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070404/6105b407/attachment-0001.html 

From kaushik.ghose at gmail.com  Wed Apr  4 11:44:58 2007
From: kaushik.ghose at gmail.com (kaushik.ghose)
Date: Wed, 04 Apr 2007 11:44:58 -0400
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
Message-ID: <4613C7FA.1050106@gmail.com>

Pete DeLaurentis wrote:

> Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3 as a 
service. I have no problems with the service shutting down or becoming 
unresponsive. I run this on a laptop, (with hibernation) uptime upto 50 
hrs hasn't been a problem.

The "500 Internal Server Error" rings a bell, but I can't remember what 
was causing it and the issue has been resolved for me.

-Kaushik



From rsanheim at gmail.com  Wed Apr  4 11:56:56 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Wed, 4 Apr 2007 10:56:56 -0500
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <20070404103737.81c8e0a9.zedshaw@zedshaw.com>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<20070404103737.81c8e0a9.zedshaw@zedshaw.com>
Message-ID: <fc113d400704040856k1c6d1f07l623ef2b8d0e561b7@mail.gmail.com>

On 4/4/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> Third, whenever you do an upgrade you have to recompile ALL of your
> gems.  Every last one.  No matter what.  Best way to do this is
> uninstall all of your gems then reinstall the ones you need.  It's good
> spring cleaning, but it also makes sure that the compiled extensions
> work with the new ruby interpreter.

You are referring here to *only* when you do an upgrade of the ruby
intrepreter, right?

- Rob

From pete at nextengine.com  Wed Apr  4 12:29:35 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 09:29:35 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <4613BC31.5060803@urbacon.net>
References: <9BA1269C-DFE6-4BBA-BA87-455C1B19A059@nextengine.com>
	<4613BC31.5060803@urbacon.net>
Message-ID: <F843192F-E26A-4F68-BB25-0F529FDC8FE8@nextengine.com>

Yeah, I've been bitten by this one before too... in one of the  
background processes I run.  Now that background process bites  
ActiveRecord every hour to keep it alive.

I've never had any trouble with activerecord losing it's connection  
in the mongrel processes, but it sounds like it's possible.  Maybe I  
should have that background process contact each of the mongrels.  Or  
better yet, maybe I should look into how hard it would be to get  
ActiveRecord to restore the connection.

Thanks,
Pete


On Apr 4, 2007, at 7:54 AM, Matt Zukowski wrote:

> Are you sure this isn't being caused by something unrelated to mongrel
> or ruby 1.8.6? We were having a similar problem a while ago and traced
> it down mysql closing its connection after 8 hours of inactivity
> (ActiveRecord, somewhat stupidly, does not attempt to reconnect the
> closed connection).
>
> Pete DeLaurentis wrote:
>> Hi guys,
>>
>> I've been running mongrel for a while now with Ruby 1.8.4, and last
>> week upgraded to 1.8.6.
>>
>> Since upgrading, each morning when I wake up there's a big problem:
>>
>> 1. Accessing the site returns a "500 Internal Server Error"
>> 2. All the mongrel_rails processes are still running, but none of
>> them are active (when I run top)
>> 3. Lighttpd and pound are still running nicely
>> 4. There's plenty of free RAM
>> 5. There's plenty of free HD
>> 6. When I restart mongrel, it all starts working again
>>
>> I haven't seen anything like this before.  Does this sound familiar
>> to anyone?
>>
>> Thanks for the help,
>> Pete
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
> This e-mail message is privileged, confidential and subject to  
> copyright. Any unauthorized use or disclosure is prohibited.
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et  
> soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de  
> le divulguer sans autorisation.
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From luislavena at gmail.com  Wed Apr  4 12:38:08 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 4 Apr 2007 13:38:08 -0300
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <4613C7FA.1050106@gmail.com>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
	<4613C7FA.1050106@gmail.com>
Message-ID: <71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>

On 4/4/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
> Pete DeLaurentis wrote:
>
> > Here's a question: Is anyone running ruby1.8.6 succesfully with mongrel?
> On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3 as a
> service. I have no problems with the service shutting down or becoming
> unresponsive. I run this on a laptop, (with hibernation) uptime upto 50
> hrs hasn't been a problem.
>

Hehehe, is good to know that you are up and running Kaus ;-)

> The "500 Internal Server Error" rings a bell, but I can't remember what
> was causing it and the issue has been resolved for me.
>

Maybe MySql timeout? from mongrel faq [1]

Q. Mongrel stops working if it's left alone for a long time.

If you find that Mongrel stops working after a long idle time and
you're using MySQL then you're hitting a bug in the MySQL driver that
doesn't properly timeout connections. What happens is the MySQL server
side of the connection times out and closes, but the MySQL client
doesn't detect this and just sits there.

What you have to do is set:

ActiveRecord::Base.verification_timeout = 14400

Or to any value that is lower than the MySQL server's
interactive_timeout setting. This will make sure that ActiveRecord
checks the connection often enough to reset the connection.


[1] http://mongrel.rubyforge.org/faq.html

-- 
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 alexey.verkhovsky at gmail.com  Wed Apr  4 13:03:14 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 4 Apr 2007 11:03:14 -0600
Subject: [Mongrel] are memory limits on mongrel possible?
In-Reply-To: <6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>
References: <2C8EF109-B46F-4E30-A347-D437230EC3C0@mosso.com>
	<6EC4D520-18CC-4BE8-9D96-0D56F46291BC@gmail.com>
Message-ID: <3945c4270704041003o694848a8m4c7fa222f17d2834@mail.gmail.com>

On 4/3/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> >  memory limits on mongrel?
> Monit is what you are looking for.

There is also Process.rlimit.
The upside of rlimit, compared to monit, is that it will kill Mongrel
BEFORE it exceeds its allocation quota. The downside is that it will
not start another.

So, if you need to defend against normal memory leaks, monit is a must
have (for restarts), while Process.rlimit can be an extra precaution
against those cases when something is trying to allocate a lot of RAM
at once, and runs the box into swapping hell before monit has a chance
to kill the offending process.

Alex

From alexey.verkhovsky at gmail.com  Wed Apr  4 13:15:20 2007
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 4 Apr 2007 11:15:20 -0600
Subject: [Mongrel] monit vs mongrel cluster
In-Reply-To: <8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>
References: <1f060c4c0704031339h6ba0ed1ej1bfdae30dbd58aa0@mail.gmail.com>
	<6B432B53-60BB-4E95-BDBC-D71C17AA5C9F@brainspl.at>
	<1f060c4c0704031500w14f5aac2ud6fc9dd6343cd4ab@mail.gmail.com>
	<28F1AC74-B104-4C51-A99A-F253C7639CA0@brainspl.at>
	<33841ac70704031619y7d90c6c1n448e887151da246a@mail.gmail.com>
	<8DFCE75B-2BCC-4963-BFF0-6ED51403A720@brainspl.at>
Message-ID: <3945c4270704041015u3ffe88fenfab607235b70ceea@mail.gmail.com>

On 4/3/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>         The reason it's not in mongrel is because bradley made the
> mongrel_cluster gem and so Zed saw no reason to add the same stuff in
> mongrel.
>
>         I have asked for a --clean option for the mongel_rails command that
> would cleanup PID"s but I haven't had time to make a patch,

Same story here. I keep meaning to sit down and write that patch for
the last 10 days or so. If you get there first, please ping me
off-list.

Another daemonization problem to look at is this: when there is no pid
file, but the port is bound to some other process, 'mongrel_rails
start' silently exits with exit code zero. Meantime, the .pid file is
created a few seconds AFTER 'mongrel_rails start' is done. This is not
as important as above, but kind of not right, and in the same area.

Alex

From pete at nextengine.com  Wed Apr  4 13:37:50 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Wed, 4 Apr 2007 10:37:50 -0700
Subject: [Mongrel] Mongrel dying daily with Ruby 1.8.6
In-Reply-To: <71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>
References: <mailman.48.1175700493.19662.mongrel-users@rubyforge.org>
	<4613C7FA.1050106@gmail.com>
	<71166b3b0704040938s589d3d5ar3cb40431a471050b@mail.gmail.com>
Message-ID: <1E2F9449-9971-4AE2-9AB7-A2FE6CBB7170@nextengine.com>

> What you have to do is set:
>
> ActiveRecord::Base.verification_timeout = 14400
>
> Or to any value that is lower than the MySQL server's
> interactive_timeout setting. This will make sure that ActiveRecord
> checks the connection often enough to reset the connection.

Sweet.  Thanks Luis.  This is exactly what I'm looking for.

-Pete




On Apr 4, 2007, at 9:38 AM, Luis Lavena wrote:

> On 4/4/07, kaushik.ghose <kaushik.ghose at gmail.com> wrote:
>> Pete DeLaurentis wrote:
>>
>>> Here's a question: Is anyone running ruby1.8.6 succesfully with  
>>> mongrel?
>> On Windows Vista I'm running Mongrel with Ruby 1.8.6, rails 1.2.3  
>> as a
>> service. I have no problems with the service shutting down or  
>> becoming
>> unresponsive. I run this on a laptop, (with hibernation) uptime  
>> upto 50
>> hrs hasn't been a problem.
>>
>
> Hehehe, is good to know that you are up and running Kaus ;-)
>
>> The "500 Internal Server Error" rings a bell, but I can't remember  
>> what
>> was causing it and the issue has been resolved for me.
>>
>
> Maybe MySql timeout? from mongrel faq [1]
>
> Q. Mongrel stops working if it's left alone for a long time.
>
> If you find that Mongrel stops working after a long idle time and
> you're using MySQL then you're hitting a bug in the MySQL driver that
> doesn't properly timeout connections. What happens is the MySQL server
> side of the connection times out and closes, but the MySQL client
> doesn't detect this and just sits there.
>
> What you have to do is set:
>
> ActiveRecord::Base.verification_timeout = 14400
>
> Or to any value that is lower than the MySQL server's
> interactive_timeout setting. This will make sure that ActiveRecord
> checks the connection often enough to reset the connection.
>
>
> [1] http://mongrel.rubyforge.org/faq.html
>
> -- 
> 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
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From ctmailinglists at googlemail.com  Wed Apr  4 18:50:14 2007
From: ctmailinglists at googlemail.com (Chris T)
Date: Wed, 04 Apr 2007 23:50:14 +0100
Subject: [Mongrel] Monit / mongel_cluster 0.2.2 / mongrel 1.0.1
Message-ID: <46142BA6.1020001@googlemail.com>

Paul
Did you ever get to the bottom of this. I'm having a similar (though possibly different) problem with a Rails app failing occasionally and on just one mongrel instance, which from the trace and behaviour seems to be ImageSceince/RubyInline related.
See my post on Rails deployment group: http://groups.google.co.uk/group/rubyonrails-deployment/browse_thread/thread/8ffd04de15bfb7a4?hl=en

Thanks
Chris
> I've fixed the below (previous post) which was simply a case of
> reading the monit manual (it nukes most of the environment settings
> when it runs the script).
>
> Now I'm in a position to debug my problem, which is (I think)
> image_science crashing mongrel during processing of an uploaded file
> with a message of: terminate called after throwing an instance of
> 'int'.
>
> I'm finding it difficult to reproduce the crash reliably as uploading
> the same file works sometimes and not others.  I've tried running
> mongrel with -B, and using killall -USR1 but nothing out of the
> ordinary is being reported.
>
> I've also tried strace-ing the mongrel process and this snippet is the
> closest I can get to something useful:
>
> open("/tmp/rpupload6375.0", O_RDONLY)   = 12 <0.000113>
> futex(0xb6179e2c, FUTEX_WAKE, 2147483647) = 0 <0.000088>
> futex(0xb60a41a4, FUTEX_WAKE, 2147483647) = 0 <0.000081>
> write(2, "terminate called after throwing an instance of \'", 48) = 48
> <0.000137>
> write(2, "int", 3)                      = 3 <0.000092>
> write(2, "\'\n", 2)                     = 2 <0.000091>
> rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 <0.000146>
> tgkill(6375, 6375, SIGABRT)             = 0 <0.000083>
> --- SIGABRT (Aborted) @ 0 (0) ---
>
> Is it perhaps some sort of file locking issue?   Any ideas on how I
> could go about better tracking down the problem?
>
> Thanks,
> - Paul


From blindance at gmail.com  Thu Apr  5 03:55:36 2007
From: blindance at gmail.com (blindance at gmail.com)
Date: Thu, 5 Apr 2007 16:55:36 +0900
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
	<71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
Message-ID: <474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>

>I'll like to know from Vista users that hang on the list about their
>results too, since WinAPI is always a pain to get working on different
>platforms.

okay, results are;


Vista64:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1844      proc_info.exe
 Module32First (PID, name): 1844           proc_info.exe
 GetProcessImageFileName (PID, name): 1844
\Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 1968      <unknown>
 Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
 GetLastError: 299Only part of a ReadProcessMemory or
WriteProcessMemory request was completed.
 <unknown>
 GetProcessImageFileName (PID, name): 1968
\Device\HarddiskVolume1\Windows\System32\cmd.exe



Vista32:
 *** CURRENT PROCESS ***
 EnumProcessModules (PID, name): 1468      proc_info.exe
 Module32First (PID, name): 1468           proc_info.exe
 GetProcessImageFileName (PID, name): 1468
\Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe

 *** PARENT PROCESS ***
 EnumProcessModules (PID, name): 3944      cmd.exe
 Module32First (PID, name): 3944           cmd.exe
 GetProcessImageFileName (PID, name): 3944
\Device\HarddiskVolume1\Windows\System32\cmd.exe

From luislavena at gmail.com  Thu Apr  5 06:58:03 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 5 Apr 2007 07:58:03 -0300
Subject: [Mongrel] mongrel_service fails to get "service.exe" from ppid?
In-Reply-To: <474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>
References: <474e0f150703260500m82ebc32h7a84f72700a0b58b@mail.gmail.com>
	<71166b3b0703260803h3dbe85c2se24f338a294058a6@mail.gmail.com>
	<474e0f150703270417l6a15b0e0sad83c1c03752617b@mail.gmail.com>
	<71166b3b0703270444y37033d10h2c1295fe5cd50446@mail.gmail.com>
	<71166b3b0703302013v136dcecdp57b92948df22060b@mail.gmail.com>
	<474e0f150704020443y54de5f07od1cac196b70d7640@mail.gmail.com>
	<71166b3b0704020948t16d62047i11197d84591dd7f8@mail.gmail.com>
	<474e0f150704030349j22c2c689kac5bb40a64e03cca@mail.gmail.com>
	<71166b3b0704030913k233ca8cy6c6f026ab5ebcf41@mail.gmail.com>
	<474e0f150704050055s2d67deb8tdbf7669e0beb994f@mail.gmail.com>
Message-ID: <71166b3b0704050358s5270bb1dxbee0cf6113d7a426@mail.gmail.com>

On 4/5/07, blindance at gmail.com <blindance at gmail.com> wrote:
> >I'll like to know from Vista users that hang on the list about their
> >results too, since WinAPI is always a pain to get working on different
> >platforms.
>
> okay, results are;
>
>
> Vista64:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1844      proc_info.exe
>  Module32First (PID, name): 1844           proc_info.exe
>  GetProcessImageFileName (PID, name): 1844
> \Device\HarddiskVolume1\Users\fukuoka\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 1968      <unknown>
>  Module32First (PID, name): 1968           Error Creating Snap (SNAPMODULE)
>  GetLastError: 299Only part of a ReadProcessMemory or
> WriteProcessMemory request was completed.
>  <unknown>
>  GetProcessImageFileName (PID, name): 1968
> \Device\HarddiskVolume1\Windows\System32\cmd.exe
>
>
>
> Vista32:
>  *** CURRENT PROCESS ***
>  EnumProcessModules (PID, name): 1468      proc_info.exe
>  Module32First (PID, name): 1468           proc_info.exe
>  GetProcessImageFileName (PID, name): 1468
> \Device\HarddiskVolume1\Users\test\Desktop\proc_info_3\proc_info.exe
>
>  *** PARENT PROCESS ***
>  EnumProcessModules (PID, name): 3944      cmd.exe
>  Module32First (PID, name): 3944           cmd.exe
>  GetProcessImageFileName (PID, name): 3944
> \Device\HarddiskVolume1\Windows\System32\cmd.exe


Perfect!, that means the API is forward compatible.

Ok, will patch mongrel tonight and do a pre-release tomorrow morning.

Thank you guys for testing and providing feedback.

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 bhjackson at gmail.com  Fri Apr  6 01:00:02 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 02:00:02 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
Message-ID: <cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>

> Are you running these tests cold? You probably want to throw out the
> first bunch of requests (say, 1000) to better simulate real-world
> running conditions.

You mean disregard them in the stats? Would you mind explaining this a
little more?

> Also, what's up with the non-2xx responses? Are you benchmarking an
> error page or something?

No, maybe because I'm hitting eship.com.br and not www.eship.com.br
it's throwing a 301? Will have to double-check my setup.

From bhjackson at gmail.com  Fri Apr  6 01:00:30 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 02:00:30 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<683a886f0704031458v722f6373o4c7a1b31dfbfe9b0@mail.gmail.com>
Message-ID: <cb03bffe0704052200p597f0cf6v98aaa9c8d05c9430@mail.gmail.com>

> You might try a more current version of Nginx and see if the proxying
> performance has improved compared to the FastCGI support. You're using
> a fairly old version.
>
> http://nginx.net/CHANGES

Will check this out and report the results. Thanks :)

From njvack at wisc.edu  Fri Apr  6 09:52:49 2007
From: njvack at wisc.edu (Nathan Vack)
Date: Fri, 6 Apr 2007 08:52:49 -0500
Subject: [Mongrel] FastCGI performing better than Mongrel - what am
	I	doing wrong?
In-Reply-To: <cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
Message-ID: <27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>

On Apr 6, 2007, at 12:00 AM, Benjamin Jackson wrote:

>> Are you running these tests cold? You probably want to throw out the
>> first bunch of requests (say, 1000) to better simulate real-world
>> running conditions.
>
> You mean disregard them in the stats? Would you mind explaining this a
> little more?

Right after you start a lot of processes, there's a bunch of  
optimization that takes place -- frequently used files are read into  
cache, database connections are set up, necessary parts of the  
operating system are paged into memory, perhaps your VM is setting  
itself up, maybe Rails is generating caches...

All of this stuff takes time, and can make requests really slow.  
Fortunately, you almost never run Rails immediately after startup  
(unless you're using rmagick or something ;-) so throwing out the  
data with that startup hit will give you a better idea of how your  
site will perform in the real world.

In your case, it looked to me like Mongrel's median times were faster  
-- your totals were longer because of a very large max time.

-Nate


From francois.beausoleil at gmail.com  Fri Apr  6 11:30:01 2007
From: francois.beausoleil at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Beausoleil?=)
Date: Fri, 6 Apr 2007 11:30:01 -0400
Subject: [Mongrel] Problem using a configuration file
Message-ID: <41d5fadf0704060830g60b81edbuef5baacb1018c6b8@mail.gmail.com>

Hi all,

I'm trying to start Mongrel using a configuration file, but Mongrel complains:
$ sudo mongrel_rails start --config
/usr/local/www/xltester.com/config/mongrel.yml
!!! Path to log file not valid: log/mongrel.log
mongrel::start reported an error. Use mongrel_rails mongrel::start -h
to get help.

I'm using sudo above to replicate monit, not because I run Mongrel as
root.  Here's Mongrel's config file:

$ cat /usr/local/www/xltester.com/config/mongrel.yml
---
:environment: production
:host: 127.0.0.1
:config_file:
:group: xltester
:num_processors: 1024
:docroot: /usr/local/www/xltester.com/public
:port: "4785"
:prefix:
:mime_map:
:cwd: /usr/local/www/xltester.com
:debug: false
:daemon: true
:log_file: /usr/local/www/xltester.com/log/mongrel.log
:includes:
- mongrel
:user: xltester
:pid_file: /usr/local/www/xltester.com/log/mongrel.4785.pid
:timeout: 0
:config_script:

The permissions are:
$ ls -ld /usr/local/www/xltester.com/config
drwx------ 5 xltester xltester 4096 2007-04-06 13:35
/usr/local/www/xltester.com/config
$ ls -ld /usr/local/www/xltester.com/config/mongrel.yml
-rw------- 1 xltester xltester 426 2007-04-06 13:34
/usr/local/www/xltester.com/config/mongrel.yml

Mongrel's log files stay empty, and the PID file is obviously not generated.

At first, I had specified the log_file, pid_file and docroot options
as relative paths to cwd, but Mongrel complained with the same message
as above.

Anyway, what am I doing wrong here ?

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

From bhjackson at gmail.com  Fri Apr  6 12:53:38 2007
From: bhjackson at gmail.com (Benjamin Jackson)
Date: Fri, 6 Apr 2007 13:53:38 -0300
Subject: [Mongrel] FastCGI performing better than Mongrel - what am I
	doing wrong?
In-Reply-To: <27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>
References: <cb03bffe0704031333w6d02e4b9x475a2c151867d356@mail.gmail.com>
	<CC47FD31-FA67-410D-B9C7-82EDBEB4754D@wisc.edu>
	<cb03bffe0704052200u6226fc9cwa70c4fe8c6e6c5ac@mail.gmail.com>
	<27EF4F88-D36D-4E03-8274-E8AB41CF3337@wisc.edu>
Message-ID: <cb03bffe0704060953vc305e7fmcfa6a6445360d6b8@mail.gmail.com>

> Right after you start a lot of processes, there's a bunch of
> optimization that takes place -- frequently used files are read into
> cache, database connections are set up, necessary parts of the
> operating system are paged into memory, perhaps your VM is setting
> itself up, maybe Rails is generating caches...
>
> All of this stuff takes tim