Mongrel users - Nov 2006 - memory issues -- mongrel part of the problem?

Hi.  I''m a fairly new mongrel user and have a scenario that I wanted
to run by you all, see if anyone''s synapses connect -- mine def.
aren''t!

I''m running a fairly simple rails app through a mongrel cluster (2
mongrels).  This site is consistently sloooow -- memory on the server
is regularly paging (and shouldn''t be).   ssh-ing in and running top
shows these two mongrel processes taking up about 80% of the 1 gig of
system memory.

the only interesting thing the application is doing is storing photos
in the database and resizing the photos on the way out using
mini_magick.  Once the photos are delivered once they are cached using
rails page caching (i''m positive the caching is working,
production.log says so).

So, at this point the site should only be delivering images from the
cache (which is currently on disk) apache isn''t serving the images,
mongrel is.  -- but, things are slow.  Does this ring any bells for
anyone?

you can check the site out (don''t pound too hard please! ;) )
http://prughrealestate.com
click on the "developments" tab to see what i mean -- those thumbnail
images are coming from the cache.

Also:
Server :  Fedora Core 5
Mongrel: 0.3.13.3
mongrel_cluster: 0.2.0

I''m eternally grateful to anyone who can help me out with this!  Sort
of at the end of my rope.
Thanks in advance, & hope your Tuesday is good.

Clint

-- 
clint troxel _ Open End Studios _
307.413.0366
http://openendstudios.com

On 11/14/06, Clint Troxel <clint at ctro.net>
wrote:
> Hi.  I''m a fairly new mongrel user and have a scenario that I
wanted
> to run by you all, see if anyone''s synapses connect -- mine def.
> aren''t!
>
> I''m running a fairly simple rails app through a mongrel cluster (2
> mongrels).  This site is consistently sloooow -- memory on the server
> is regularly paging (and shouldn''t be).   ssh-ing in and running
top
> shows these two mongrel processes taking up about 80% of the 1 gig of
> system memory.
>
> the only interesting thing the application is doing is storing photos
> in the database and resizing the photos on the way out using
> mini_magick.  Once the photos are delivered once they are cached using
> rails page caching (i''m positive the caching is working,
> production.log says so).
>
> So, at this point the site should only be delivering images from the
> cache (which is currently on disk) apache isn''t serving the
images,
> mongrel is.  -- but, things are slow.  Does this ring any bells for
> anyone?
>
> you can check the site out (don''t pound too hard please! ;) )
> http://prughrealestate.com
> click on the "developments" tab to see what i mean -- those
thumbnail
> images are coming from the cache.
>
> Also:
> Server :  Fedora Core 5
> Mongrel: 0.3.13.3
> mongrel_cluster: 0.2.0
>
> I''m eternally grateful to anyone who can help me out with this! 
Sort
> of at the end of my rope.
> Thanks in advance, & hope your Tuesday is good.
Hi,

from what I''ve heard, it''s better to have apache serve the
files -
it''s faster and doesn''t interfere with ruby''s garbage
collector.

Then, I''d suspect the resizing eats the memory and slows down. To know
the
precise number, try profiling it, both outside and inside mongrel and rails.
Look for some forgotten reference to the image. Also look for the
trends - whether memory consumption grows (you have a leak or hanging
reference somewhere) or oscillates.

Hi Clint,
  Yes Mongrel did have memory issues back at 0.13.3  Please upgrade
and keep an eye on each mongrel to see if it develops a memory growth
trend.  If you search this forum there are posts by Zed and others as
to how to do said monitoring.

Good Luck,
Rob Kaufman

On 11/14/06, Clint Troxel <clint at ctro.net>
wrote:
> Hi.  I''m a fairly new mongrel user and have a scenario that I
wanted
> to run by you all, see if anyone''s synapses connect -- mine def.
> aren''t!
>
> I''m running a fairly simple rails app through a mongrel cluster (2
> mongrels).  This site is consistently sloooow -- memory on the server
> is regularly paging (and shouldn''t be).   ssh-ing in and running
top
> shows these two mongrel processes taking up about 80% of the 1 gig of
> system memory.
>
> the only interesting thing the application is doing is storing photos
> in the database and resizing the photos on the way out using
> mini_magick.  Once the photos are delivered once they are cached using
> rails page caching (i''m positive the caching is working,
> production.log says so).
>
> So, at this point the site should only be delivering images from the
> cache (which is currently on disk) apache isn''t serving the
images,
> mongrel is.  -- but, things are slow.  Does this ring any bells for
> anyone?
>
> you can check the site out (don''t pound too hard please! ;) )
> http://prughrealestate.com
> click on the "developments" tab to see what i mean -- those
thumbnail
> images are coming from the cache.
>
> Also:
> Server :  Fedora Core 5
> Mongrel: 0.3.13.3
> mongrel_cluster: 0.2.0
>
> I''m eternally grateful to anyone who can help me out with this! 
Sort
> of at the end of my rope.
> Thanks in advance, & hope your Tuesday is good.
>
> Clint
>
> --
> clint troxel _ Open End Studios _
> 307.413.0366
> http://openendstudios.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

On Tue, 14 Nov 2006 12:08:29 -0700
"Clint Troxel" <clint at ctro.net> wrote:
> the only interesting thing the application is doing is storing photos
> in the database and resizing the photos on the way out using
> mini_magick.  Once the photos are delivered once they are cached using
> rails page caching (i''m positive the caching is working,
> production.log says so).
The #1 cause of problems when running Mongrel seems to be "I''m
just doing <insert file store in database> with <insert image
modification using RMagick>."  I''d look at a way to move that
outside of rails with BackgrounDRb.

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

> The #1 cause of problems when running Mongrel seems to be
"I''m just doing <insert file store in database> with
<insert image modification using RMagick>."  I''d look at a
way to move that outside of rails with BackgrounDRb.
To his credit he is using mini magick instead.  It just issues system
commands against the image magick command if I''m not mistaken.

-- 
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com

A quick question (since answers to all such threads is to offload
tasks to backgroundrb): If I set load_rails to true in backgroundrb
configuration, does that hurt things? [are some mongrel threads
involved & blocking then?]

Vish

On 11/15/06, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
> On Tue, 14 Nov 2006 12:08:29 -0700
> "Clint Troxel" <clint at ctro.net> wrote:
>
> > the only interesting thing the application is doing is storing photos
> > in the database and resizing the photos on the way out using
> > mini_magick.  Once the photos are delivered once they are cached using
> > rails page caching (i''m positive the caching is working,
> > production.log says so).
>
> The #1 cause of problems when running Mongrel seems to be
"I''m just doing <insert file store in database> with
<insert image modification using RMagick>."  I''d look at a
way to move that outside of rails with BackgrounDRb.
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

So, I realize that all answers point to offloading to backgroundrb -- but...

 1) RMagick isn''t being used.... or loaded into the mongrel memory
space -- using mini_magick.
 2) These images are being served from the cache -- at this point
there isn''t any mini_magick (or RMagick!) being excecuted -- just
files served from the rails cache.

Is the recommendation still to use backgroundrb?  Seems that serving a
static file from the cache shouldn''t be a time intensive op.

happy to be informed,
Clint

On 11/14/06, Vishnu Gopal <g.vishnu at gmail.com>
wrote:
> A quick question (since answers to all such threads is to offload
> tasks to backgroundrb): If I set load_rails to true in backgroundrb
> configuration, does that hurt things? [are some mongrel threads
> involved & blocking then?]
>
> Vish
>
> On 11/15/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > On Tue, 14 Nov 2006 12:08:29 -0700
> > "Clint Troxel" <clint at ctro.net> wrote:
> >
> > > the only interesting thing the application is doing is storing
photos
> > > in the database and resizing the photos on the way out using
> > > mini_magick.  Once the photos are delivered once they are cached
using
> > > rails page caching (i''m positive the caching is working,
> > > production.log says so).
> >
> > The #1 cause of problems when running Mongrel seems to be
"I''m just doing <insert file store in database> with
<insert image modification using RMagick>."  I''d look at a
way to move that outside of rails with BackgrounDRb.
> >
> > --
> > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> > http://www.zedshaw.com/
> > http://www.awprofessional.com/title/0321483502 -- The Mongrel Book
> > http://mongrel.rubyforge.org/
> > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

-- 
clint troxel _ Open End Studios _
307.413.0366
http://openendstudios.com

I''ve been using RMagick within my rails apps for all my image
manipulation needs so far. I have been wondering about how the image
stuff was handled memory wise. Everything has been running smoothly so
far so I didn''t really worry about it. In the future though, what
would be the better approach?

1) Using mini_magick within my rails apps
2) Using RMagick in a BackgroundRB process
- 1+2

I''m guessing that if mini_magick doesn''t load anything into
memory,
running it inside the rails app should be fine?

Thanks,
-carl

On 11/14/06, Clint Troxel <clint at ctro.net>
wrote:
> So, I realize that all answers point to offloading to backgroundrb --
but...
>
>  1) RMagick isn''t being used.... or loaded into the mongrel memory
> space -- using mini_magick.
>  2) These images are being served from the cache -- at this point
> there isn''t any mini_magick (or RMagick!) being excecuted -- just
> files served from the rails cache.
>
> Is the recommendation still to use backgroundrb?  Seems that serving a
> static file from the cache shouldn''t be a time intensive op.
>
> happy to be informed,
> Clint
>
> On 11/14/06, Vishnu Gopal <g.vishnu at gmail.com> wrote:
> > A quick question (since answers to all such threads is to offload
> > tasks to backgroundrb): If I set load_rails to true in backgroundrb
> > configuration, does that hurt things? [are some mongrel threads
> > involved & blocking then?]
> >
> > Vish
> >
> > On 11/15/06, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> > > On Tue, 14 Nov 2006 12:08:29 -0700
> > > "Clint Troxel" <clint at ctro.net> wrote:
> > >
> > > > the only interesting thing the application is doing is
storing photos
> > > > in the database and resizing the photos on the way out using
> > > > mini_magick.  Once the photos are delivered once they are
cached using
> > > > rails page caching (i''m positive the caching is
working,
> > > > production.log says so).
> > >
> > > The #1 cause of problems when running Mongrel seems to be
"I''m just doing <insert file store in database> with
<insert image modification using RMagick>."  I''d look at a
way to move that outside of rails with BackgrounDRb.
> > >
> > > --
> > > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> > > http://www.zedshaw.com/
> > > http://www.awprofessional.com/title/0321483502 -- The Mongrel
Book
> > > http://mongrel.rubyforge.org/
> > > http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> > > _______________________________________________
> > > Mongrel-users mailing list
> > > Mongrel-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mongrel-users
> > >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
> --
> clint troxel _ Open End Studios _
> 307.413.0366
> http://openendstudios.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

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

We are using RMagick / mongrel / apache, and recently had to run a  
migration that had to process approximately 7000 images, by  
generating a thumbnail and a JPEG out of a large PNG.

The migration took about 5 minutes to complete, and while it was  
running I was watching the RAM/CPU of the rake process that was  
running it.  The process RSS was fluctuating between 200Mb and  
500Mb... It seems like once the garbage collection kicked in, the RSS  
went down by up to 300Mb, and then slowly climb back up.   Clearly,  
this is a very high memory footprint for a web server process, but  
should be acceptable for a dedicated background process.

Thanks
Konstantin


On Nov 15, 2006, at 8:15 AM, Carl Lerche wrote:
> I''ve been using RMagick within my rails apps for all my image
> manipulation needs so far. I have been wondering about how the image
> stuff was handled memory wise. Everything has been running smoothly so
> far so I didn''t really worry about it. In the future though, what
> would be the better approach?
>
> 1) Using mini_magick within my rails apps
> 2) Using RMagick in a BackgroundRB process
> - 1+2
>
> I''m guessing that if mini_magick doesn''t load anything
into memory,
> running it inside the rails app should be fine?

I''ll jump in on this one too.
We''ve found about the same when using RMagick with mongrel.
We''ve got
sites on a dedicated server with a stack of RAM and 3 mongrel servers
per app and they seem to cope ok. However I ran another site on a VPS
with 128mb of RAM and a single mongrel server and often, depending on
the uploaded image, the server will completely lock up.

I have monit running on this server, but if it goes, it needs a root
login to force quit all processes and then a restart of the server to
cure, monit won''t restart it. I don''t know what everyone else
has
found, but I''d say that if you''re going to use RMagick, you
need
plenty of spare RAM capacity.



On 11/15/06, kigsteronline at mac.com <kigsteronline at mac.com>
wrote:
>
> We are using RMagick / mongrel / apache, and recently had to run a
> migration that had to process approximately 7000 images, by
> generating a thumbnail and a JPEG out of a large PNG.
>
> The migration took about 5 minutes to complete, and while it was
> running I was watching the RAM/CPU of the rake process that was
> running it.  The process RSS was fluctuating between 200Mb and
> 500Mb... It seems like once the garbage collection kicked in, the RSS
> went down by up to 300Mb, and then slowly climb back up.   Clearly,
> this is a very high memory footprint for a web server process, but
> should be acceptable for a dedicated background process.
>
> Thanks
> Konstantin
>
>
> On Nov 15, 2006, at 8:15 AM, Carl Lerche wrote:
>
> > I''ve been using RMagick within my rails apps for all my image
> > manipulation needs so far. I have been wondering about how the image
> > stuff was handled memory wise. Everything has been running smoothly so
> > far so I didn''t really worry about it. In the future though,
what
> > would be the better approach?
> >
> > 1) Using mini_magick within my rails apps
> > 2) Using RMagick in a BackgroundRB process
> > - 1+2
> >
> > I''m guessing that if mini_magick doesn''t load
anything into memory,
> > running it inside the rails app should be fine?
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

-- 
Ross Riley
www.sorrylies.com

So what''s going on here is that RMagick allocates memory in a way that
isn''t visible to the ruby garbage collector. If you don''t have
500Mb to
burn, you can manually start garbage collection more often (as long as
your RMagick objects are passing out of scope, not still referenced
somewhere).

Tim said it way better:
http://rubyforge.org/forum/forum.php?thread_id=1374&forum_id=1618

phil


kigsteronline at mac.com wrote:
> We are using RMagick / mongrel / apache, and recently had to run a  
> migration that had to process approximately 7000 images, by  
> generating a thumbnail and a JPEG out of a large PNG.
>
> The migration took about 5 minutes to complete, and while it was  
> running I was watching the RAM/CPU of the rake process that was  
> running it.  The process RSS was fluctuating between 200Mb and  
> 500Mb... It seems like once the garbage collection kicked in, the RSS  
> went down by up to 300Mb, and then slowly climb back up.   Clearly,  
> this is a very high memory footprint for a web server process, but  
> should be acceptable for a dedicated background process.
>
> Thanks
> Konstantin
>
>
> On Nov 15, 2006, at 8:15 AM, Carl Lerche wrote:
>
>   
>> I''ve been using RMagick within my rails apps for all my image
>> manipulation needs so far. I have been wondering about how the image
>> stuff was handled memory wise. Everything has been running smoothly so
>> far so I didn''t really worry about it. In the future though,
what
>> would be the better approach?
>>
>> 1) Using mini_magick within my rails apps
>> 2) Using RMagick in a BackgroundRB process
>> - 1+2
>>
>> I''m guessing that if mini_magick doesn''t load
anything into memory,
>> running it inside the rails app should be fine?
>>     
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>   

-- 
Phillip Kast
(909)630-9562
phil at unimedia.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20061115/70310e26/attachment.html

I don''t know where people get the idea that image processing is not a 
memory-intensive process.  Most image formats are compressed, heavily in 
some cases. magicked needs to uncompress the image, apply the 
transforms, and re-compress it back to disk... all in-memory.  Throw in 
some concurrency, and your memory usage will spiral.

Just as a point of reference, I have been working on a set of comps at 
work.  The photoshop file is 32 Mb on disk.  In memory, before doing 
anything, photoshop''s memory usage climbs to 1.2 Gb(!). Sure, a bit 
extreme, but it illustrates my point.

=Will Green

Just put an app into production, and I''ve got monit watching the
mongrel cluster. If an instance gets above 75mb for more than 2.5
minutes, that mongrel is restarted. I''ve actually had them restart a
few times now. It''s something that I''ll be looking into over
the next
couple of weeks though.

On 11/15/06, Ross Riley <riley.ross at gmail.com>
wrote:
> I''ll jump in on this one too.
> We''ve found about the same when using RMagick with mongrel.
We''ve got
> sites on a dedicated server with a stack of RAM and 3 mongrel servers
> per app and they seem to cope ok. However I ran another site on a VPS
> with 128mb of RAM and a single mongrel server and often, depending on
> the uploaded image, the server will completely lock up.
>
> I have monit running on this server, but if it goes, it needs a root
> login to force quit all processes and then a restart of the server to
> cure, monit won''t restart it. I don''t know what everyone
else has
> found, but I''d say that if you''re going to use RMagick,
you need
> plenty of spare RAM capacity.
>
>
>
> On 11/15/06, kigsteronline at mac.com <kigsteronline at mac.com>
wrote:
> >
> > We are using RMagick / mongrel / apache, and recently had to run a
> > migration that had to process approximately 7000 images, by
> > generating a thumbnail and a JPEG out of a large PNG.
> >
> > The migration took about 5 minutes to complete, and while it was
> > running I was watching the RAM/CPU of the rake process that was
> > running it.  The process RSS was fluctuating between 200Mb and
> > 500Mb... It seems like once the garbage collection kicked in, the RSS
> > went down by up to 300Mb, and then slowly climb back up.   Clearly,
> > this is a very high memory footprint for a web server process, but
> > should be acceptable for a dedicated background process.
> >
> > Thanks
> > Konstantin
> >
> >
> > On Nov 15, 2006, at 8:15 AM, Carl Lerche wrote:
> >
> > > I''ve been using RMagick within my rails apps for all my
image
> > > manipulation needs so far. I have been wondering about how the
image
> > > stuff was handled memory wise. Everything has been running
smoothly so
> > > far so I didn''t really worry about it. In the future
though, what
> > > would be the better approach?
> > >
> > > 1) Using mini_magick within my rails apps
> > > 2) Using RMagick in a BackgroundRB process
> > > - 1+2
> > >
> > > I''m guessing that if mini_magick doesn''t load
anything into memory,
> > > running it inside the rails app should be fine?
> >
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> >
>
>
> --
> Ross Riley
> www.sorrylies.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

Phillip, thanks for this tip,

We had a customer (www.curbly.com) that made lifehacker and the front
page of digg yesterday and had some Rmagick resizing on account signup
(and other places).  We re-deployed with the GC.start fixes during the
on-slaught (the box hit 30.0+ load) and after that, she performed a
lot better (normally -- load well under 1.0).  The box was running
apache 2.2.2 (mpm-prefork) with mod_proxy_balancer and 3 mongrel
instances (!)

Thanks!
-- 
Charles Brian Quinn
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com

On 11/15/06, Phillip Kast <phil at unimedia.org>
wrote:
>
>  So what''s going on here is that RMagick allocates memory in a way
that
> isn''t visible to the ruby garbage collector. If you don''t
have 500Mb to
> burn, you can manually start garbage collection more often (as long as your
> RMagick objects are passing out of scope, not still referenced somewhere).
>
>  Tim said it way better:
> http://rubyforge.org/forum/forum.php?thread_id=1374&forum_id=1618
>
>  phil
>
>
>
>  kigsteronline at mac.com wrote:
>  We are using RMagick / mongrel / apache, and recently had to run a
> migration that had to process approximately 7000 images, by
> generating a thumbnail and a JPEG out of a large PNG.
>
> The migration took about 5 minutes to complete, and while it was
> running I was watching the RAM/CPU of the rake process that was
> running it. The process RSS was fluctuating between 200Mb and
> 500Mb... It seems like once the garbage collection kicked in, the RSS
> went down by up to 300Mb, and then slowly climb back up. Clearly,
> this is a very high memory footprint for a web server process, but
> should be acceptable for a dedicated background process.
>
> Thanks
> Konstantin
>
>
> On Nov 15, 2006, at 8:15 AM, Carl Lerche wrote:
>
>
>
>  I''ve been using RMagick within my rails apps for all my image
> manipulation needs so far. I have been wondering about how the image
> stuff was handled memory wise. Everything has been running smoothly so
> far so I didn''t really worry about it. In the future though, what
> would be the better approach?
>
> 1) Using mini_magick within my rails apps
> 2) Using RMagick in a BackgroundRB process
> - 1+2
>
> I''m guessing that if mini_magick doesn''t load anything
into memory,
> running it inside the rails app should be fine?
>
>  _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
>
>
>  --
> Phillip Kast
> (909)630-9562
> phil at unimedia.org
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>

On Sat, Nov 18, 2006 at 11:45:30AM -0500, Charles Brian Quinn
wrote:
> Phillip, thanks for this tip,
> 
> We had a customer (www.curbly.com) that made lifehacker and the front
> page of digg yesterday and had some Rmagick resizing on account signup
> (and other places).  We re-deployed with the GC.start fixes during the
> on-slaught (the box hit 30.0+ load) and after that, she performed a
> lot better (normally -- load well under 1.0).  The box was running
> apache 2.2.2 (mpm-prefork) with mod_proxy_balancer and 3 mongrel
> instances (!)
Just curious, what OS are you running on? How many hits/second were you
taking?

-- 
Cheers,
- Jacob Atzen

I apologize if this is email is out of place on this list, but I was  
wondering if anyone here can suggest a good / reliable Rails /  
Mongrel hosting solutions?  I need something where I can host  
multiple applications (preferebly with PostgreSQL) for no more than  
$10/ month.  I need fast SSH access and ideally capistrano.

So far I found site5, dreamhost, hostingrails and a2hosting that fall  
into this price point, so if anyone has any suggestions or opinions  
on the above please email me directly.

Thank you,
Konstantin

If you''re ok running on a shared server then the ones you said +
textdrive would probably be ok.
I would say that if you''re going to be doing anything commercial you
should probably consider a VPS, I personally use Rimuhosting and their
basic VPS is $20 per month.

Shared servers are fine for smaller projects but are vulnerable to
performance fluctuations, in the past I''ve had mongrel instances
running out of memory completely. At least with a VPS you always have
a stable performance guarantee, which if you''ve got clients constantly
ringing you is worth paying the extra for peace of mind.

Ross

On 11/20/06, kigsteronline at mac.com <kigsteronline at mac.com>
wrote:
> I apologize if this is email is out of place on this list, but I was
> wondering if anyone here can suggest a good / reliable Rails /
> Mongrel hosting solutions?  I need something where I can host
> multiple applications (preferebly with PostgreSQL) for no more than
> $10/ month.  I need fast SSH access and ideally capistrano.
>
> So far I found site5, dreamhost, hostingrails and a2hosting that fall
> into this price point, so if anyone has any suggestions or opinions
> on the above please email me directly.
>
> Thank you,
> Konstantin
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

-- 
Ross Riley
www.sorrylies.com