Like most, I have a test and a production env. Both are CentOS 5, Ruby 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the same procedure. Except for the hardware (test: Intel, prod: AMD) and memory (test: 512M, prod: 1G), both systems are essentially the same right down to the Rails env. Unfortunately, memory usage is very different for each. The test system has 2 mongrel instances running. According to top, they start at around 50M memory, but within a few pages they are quickly up to 100M. The production systems have 5 mongrels, and they start at around 50M as well. However, hit them with thousands of page views and their memory usage rarely passes 60M. It''s almost as if the GC isn''t running on the test system. There is still plenty of free memory on the prod system (148M). The test system will usually use it all up and often begin swapping. Any thoughts? Any ideas where I might look? I prefer to not even pay for the 512M VM for the test system, but it doesn''t seem to want to conserve memory. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
are they both run in production mode? On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigdave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Like most, I have a test and a production env. Both are CentOS 5, Ruby > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > same procedure. Except for the hardware (test: Intel, prod: AMD) and > memory (test: 512M, prod: 1G), both systems are essentially the same > right down to the Rails env. Unfortunately, memory usage is very > different for each. > > The test system has 2 mongrel instances running. According to top, > they start at around 50M memory, but within a few pages they are > quickly up to 100M. The production systems have 5 mongrels, and they > start at around 50M as well. However, hit them with thousands of page > views and their memory usage rarely passes 60M. It''s almost as if the > GC isn''t running on the test system. There is still plenty of free > memory on the prod system (148M). The test system will usually use it > all up and often begin swapping. > > Any thoughts? Any ideas where I might look? I prefer to not even pay > for the 512M VM for the test system, but it doesn''t seem to want to > conserve memory. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Define production mode? They have different environments, but both
have the same setup.
config/staging.rb and config/production.rb are both:
require ''syslog_logger''
# Settings specified here will take precedence over those in config/
environment.rb
# The production environment is meant for finished, "live" apps.
# Code is not reloaded between requests
config.cache_classes = true
# Use a different logger for distributed setups
config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'')
config.logger.level = Logger::INFO
# Full error reports are disabled and caching is turned on
config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching = true
On Apr 30, 11:03 am, "Roger Pack"
<rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> are they both run in production mode?
>
> On Wed, Apr 30, 2008 at 8:45 AM, gobigdave
<gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Like most, I have a test and a production env. Both are CentOS 5,
Ruby
> > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the
> > same procedure. Except for the hardware (test: Intel, prod: AMD) and
> > memory (test: 512M, prod: 1G), both systems are essentially the same
> > right down to the Rails env. Unfortunately, memory usage is very
> > different for each.
>
> > The test system has 2 mongrel instances running. According to top,
> > they start at around 50M memory, but within a few pages they are
> > quickly up to 100M. The production systems have 5 mongrels, and they
> > start at around 50M as well. However, hit them with thousands of
page
> > views and their memory usage rarely passes 60M. It''s almost
as if the
> > GC isn''t running on the test system. There is still plenty
of free
> > memory on the prod system (148M). The test system will usually use it
> > all up and often begin swapping.
>
> > Any thoughts? Any ideas where I might look? I prefer to not even
pay
> > for the 512M VM for the test system, but it doesn''t seem to
want to
> > conserve memory.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
I think what he''s asking is if you are running the development system under development mode for your Rails application. Isn''t there a host of debugging and logging stuff going on in the background which could account for the increase in memory usage. On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Define production mode? They have different environments, but both > have the same setup. > > config/staging.rb and config/production.rb are both: > > require ''syslog_logger'' > > # Settings specified here will take precedence over those in config/ > environment.rb > > # The production environment is meant for finished, "live" apps. > # Code is not reloaded between requests > config.cache_classes = true > > # Use a different logger for distributed setups > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > config.logger.level = Logger::INFO > > # Full error reports are disabled and caching is turned on > config.action_controller.consider_all_requests_local = false > config.action_controller.perform_caching = true > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > are they both run in production mode? > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > right down to the Rails env. Unfortunately, memory usage is very > > > different for each. > > > > The test system has 2 mongrel instances running. According to top, > > > they start at around 50M memory, but within a few pages they are > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > start at around 50M as well. However, hit them with thousands of page > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > GC isn''t running on the test system. There is still plenty of free > > > memory on the prod system (148M). The test system will usually use it > > > all up and often begin swapping. > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > conserve memory.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
No, I purposely setup the staging and production environments to be the same. The log level is the same, all debug that I know of is turned off in both systems, and caching is turned on. My previous message had the environment file (exactly the same between the two), and deploy.rb is only different in the ip addresses of the target machines to install to. Does Rails look at RAILS_ENV behind the scenes and do something different? I''m aware of different defaults for logging level, but is there something else? Trying to find good documentation on this stuff is not easy (my only real problem with Rails in general). If so, then I would be concerned since you want a staging environment to be as close as possible to production as possible. I should be able to get Rails to run as production when RAILS_ENV != ''production''. What if I have two "production" environments (one is a backup)? On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I think what he''s asking is if you are running the development system > under development mode for your Rails application. Isn''t there a host > of debugging and logging stuff going on in the background which could > account for the increase in memory usage. > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Define production mode? They have different environments, but both > > have the same setup. > > > config/staging.rb and config/production.rb are both: > > > require ''syslog_logger'' > > > # Settings specified here will take precedence over those in config/ > > environment.rb > > > # The production environment is meant for finished, "live" apps. > > # Code is not reloaded between requests > > config.cache_classes = true > > > # Use a different logger for distributed setups > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > config.logger.level = Logger::INFO > > > # Full error reports are disabled and caching is turned on > > config.action_controller.consider_all_requests_local = false > > config.action_controller.perform_caching = true > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > are they both run in production mode? > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > different for each. > > > > > The test system has 2 mongrel instances running. According to top, > > > > they start at around 50M memory, but within a few pages they are > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > start at around 50M as well. However, hit them with thousands of page > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > GC isn''t running on the test system. There is still plenty of free > > > > memory on the prod system (148M). The test system will usually use it > > > > all up and often begin swapping. > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > conserve memory.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
try them both on the same ''production'' -- if it still has the leak then there must be some either ''other'' variable or ''hidden'' variable in there somewhere [though I myself have used production and ''production2'' environment''s style before and it worked fine]. -R On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigdave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > No, I purposely setup the staging and production environments to be > the same. The log level is the same, all debug that I know of is > turned off in both systems, and caching is turned on. My previous > message had the environment file (exactly the same between the two), > and deploy.rb is only different in the ip addresses of the target > machines to install to. > > Does Rails look at RAILS_ENV behind the scenes and do something > different? I''m aware of different defaults for logging level, but is > there something else? Trying to find good documentation on this stuff > is not easy (my only real problem with Rails in general). If so, then > I would be concerned since you want a staging environment to be as > close as possible to production as possible. I should be able to get > Rails to run as production when RAILS_ENV != ''production''. What if I > have two "production" environments (one is a backup)? > > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I think what he''s asking is if you are running the development system > > under development mode for your Rails application. Isn''t there a host > > of debugging and logging stuff going on in the background which could > > account for the increase in memory usage. > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Define production mode? They have different environments, but both > > > have the same setup. > > > > > config/staging.rb and config/production.rb are both: > > > > > require ''syslog_logger'' > > > > > # Settings specified here will take precedence over those in config/ > > > environment.rb > > > > > # The production environment is meant for finished, "live" apps. > > > # Code is not reloaded between requests > > > config.cache_classes = true > > > > > # Use a different logger for distributed setups > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > config.logger.level = Logger::INFO > > > > > # Full error reports are disabled and caching is turned on > > > config.action_controller.consider_all_requests_local = false > > > config.action_controller.perform_caching = true > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > are they both run in production mode? > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > different for each. > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > they start at around 50M memory, but within a few pages they are > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > memory on the prod system (148M). The test system will usually use it > > > > > all up and often begin swapping. > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > conserve memory. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Just tried again with an environment of ''production'', and the same thing happens -- a few clicks and memory grows to about 100M. Since I will be moving my production environment anyway, I built a brand new CentOS 5.1 slice (on SliceHost). I followed my original instructions which involve building Ruby 1.8.6 from source and using yum and gem for everything else. Within 5-6 page views mongrel_rails goes from 50M to 98M. That does not happen on my current production server (CentOS 5.0 on dedicated server at ServerBeach) -- after several thousand page views the mongrel processes are still at 55M. It doesn''t feel like a leak to me because it levels off and stays pretty steady. I think it''s the GC executing differently or something to that affect, but I don''t remember doing anything different when I built the original production server. At this point, I have two machines running exactly the same application using exactly the same rails config with VERY different memory usage. The only thing I can think of is something with build args or libs on ruby because everything else was done with yum and gem. I am assuming that yum and gem will install exactly the same things on both machines. BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 patchlevel 0) [x86_64-linux] What do most people see their mongrel_rails processes running at for memory? Could I be looking at a difference in the way top reports memory between CentOS 5.0 and 5.1? On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> try them both on the same ''production'' -- if it still has the leak > then there must be some either ''other'' variable or ''hidden'' variable > in there somewhere [though I myself have used production and > ''production2'' environment''s style before and it worked fine]. > -R > > On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > No, I purposely setup the staging and production environments to be > > the same. The log level is the same, all debug that I know of is > > turned off in both systems, and caching is turned on. My previous > > message had the environment file (exactly the same between the two), > > and deploy.rb is only different in the ip addresses of the target > > machines to install to. > > > Does Rails look at RAILS_ENV behind the scenes and do something > > different? I''m aware of different defaults for logging level, but is > > there something else? Trying to find good documentation on this stuff > > is not easy (my only real problem with Rails in general). If so, then > > I would be concerned since you want a staging environment to be as > > close as possible to production as possible. I should be able to get > > Rails to run as production when RAILS_ENV != ''production''. What if I > > have two "production" environments (one is a backup)? > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I think what he''s asking is if you are running the development system > > > under development mode for your Rails application. Isn''t there a host > > > of debugging and logging stuff going on in the background which could > > > account for the increase in memory usage. > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Define production mode? They have different environments, but both > > > > have the same setup. > > > > > config/staging.rb and config/production.rb are both: > > > > > require ''syslog_logger'' > > > > > # Settings specified here will take precedence over those in config/ > > > > environment.rb > > > > > # The production environment is meant for finished, "live" apps. > > > > # Code is not reloaded between requests > > > > config.cache_classes = true > > > > > # Use a different logger for distributed setups > > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > > config.logger.level = Logger::INFO > > > > > # Full error reports are disabled and caching is turned on > > > > config.action_controller.consider_all_requests_local = false > > > > config.action_controller.perform_caching = true > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > are they both run in production mode? > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > > different for each. > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > > they start at around 50M memory, but within a few pages they are > > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > > memory on the prod system (148M). The test system will usually use it > > > > > > all up and often begin swapping. > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > > conserve memory.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Do you have the exact some data set in your db in both locations? A lot of times this can happen when you start getting more data in your db and you start pulling back more rows then you think you are, this can bloat mongrels like you are seeing. -Ezra On Apr 30, 2008, at 8:59 PM, gobigdave wrote:> > Just tried again with an environment of ''production'', and the same > thing happens -- a few clicks and memory grows to about 100M. Since I > will be moving my production environment anyway, I built a brand new > CentOS 5.1 slice (on SliceHost). I followed my original instructions > which involve building Ruby 1.8.6 from source and using yum and gem > for everything else. Within 5-6 page views mongrel_rails goes from > 50M to 98M. That does not happen on my current production server > (CentOS 5.0 on dedicated server at ServerBeach) -- after several > thousand page views the mongrel processes are still at 55M. > > It doesn''t feel like a leak to me because it levels off and stays > pretty steady. I think it''s the GC executing differently or something > to that affect, but I don''t remember doing anything different when I > built the original production server. At this point, I have two > machines running exactly the same application using exactly the same > rails config with VERY different memory usage. The only thing I can > think of is something with build args or libs on ruby because > everything else was done with yum and gem. I am assuming that yum and > gem will install exactly the same things on both machines. > > BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 > patchlevel 0) [x86_64-linux] > > What do most people see their mongrel_rails processes running at for > memory? Could I be looking at a difference in the way top reports > memory between CentOS 5.0 and 5.1? > > On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> try them both on the same ''production'' -- if it still has the leak >> then there must be some either ''other'' variable or ''hidden'' variable >> in there somewhere [though I myself have used production and >> ''production2'' environment''s style before and it worked fine]. >> -R >> >> On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >>> No, I purposely setup the staging and production environments to be >>> the same. The log level is the same, all debug that I know of is >>> turned off in both systems, and caching is turned on. My previous >>> message had the environment file (exactly the same between the two), >>> and deploy.rb is only different in the ip addresses of the target >>> machines to install to. >> >>> Does Rails look at RAILS_ENV behind the scenes and do something >>> different? I''m aware of different defaults for logging level, but >>> is >>> there something else? Trying to find good documentation on this >>> stuff >>> is not easy (my only real problem with Rails in general). If so, >>> then >>> I would be concerned since you want a staging environment to be as >>> close as possible to production as possible. I should be able to >>> get >>> Rails to run as production when RAILS_ENV != ''production''. What >>> if I >>> have two "production" environments (one is a backup)? >> >>> On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>>> I think what he''s asking is if you are running the development >>>> system >>>> under development mode for your Rails application. Isn''t there a >>>> host >>>> of debugging and logging stuff going on in the background which >>>> could >>>> account for the increase in memory usage. >> >>>> On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>>>> Define production mode? They have different environments, but >>>>> both >>>>> have the same setup. >> >>>>> config/staging.rb and config/production.rb are both: >> >>>>> require ''syslog_logger'' >> >>>>> # Settings specified here will take precedence over those in >>>>> config/ >>>>> environment.rb >> >>>>> # The production environment is meant for finished, "live" apps. >>>>> # Code is not reloaded between requests >>>>> config.cache_classes = true >> >>>>> # Use a different logger for distributed setups >>>>> config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') >>>>> config.logger.level = Logger::INFO >> >>>>> # Full error reports are disabled and caching is turned on >>>>> config.action_controller.consider_all_requests_local = false >>>>> config.action_controller.perform_caching = true >> >>>>> On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>>>>> are they both run in production mode? >> >>>>>> On Wed, Apr 30, 2008 at 8:45 AM, gobigdave >>>>>> <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>>>>>> Like most, I have a test and a production env. Both are CentOS >>>>>>> 5, Ruby >>>>>>> 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup >>>>>>> using the >>>>>>> same procedure. Except for the hardware (test: Intel, prod: >>>>>>> AMD) and >>>>>>> memory (test: 512M, prod: 1G), both systems are essentially >>>>>>> the same >>>>>>> right down to the Rails env. Unfortunately, memory usage is >>>>>>> very >>>>>>> different for each. >> >>>>>>> The test system has 2 mongrel instances running. According to >>>>>>> top, >>>>>>> they start at around 50M memory, but within a few pages they are >>>>>>> quickly up to 100M. The production systems have 5 mongrels, >>>>>>> and they >>>>>>> start at around 50M as well. However, hit them with thousands >>>>>>> of page >>>>>>> views and their memory usage rarely passes 60M. It''s almost as >>>>>>> if the >>>>>>> GC isn''t running on the test system. There is still plenty of >>>>>>> free >>>>>>> memory on the prod system (148M). The test system will usually >>>>>>> use it >>>>>>> all up and often begin swapping. >> >>>>>>> Any thoughts? Any ideas where I might look? I prefer to not >>>>>>> even pay >>>>>>> for the 512M VM for the test system, but it doesn''t seem to >>>>>>> want to >>>>>>> conserve memory. > >- Ezra Zygmuntowicz -- Founder & Software Architect -- ezra-NLltGlunAUd/unjJdyJNww@public.gmane.org -- EngineYard.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
did you build from scratch both places? for me on ''big loads'' the mongrels stay at [sigh] about 120MB each. On Wed, Apr 30, 2008 at 9:59 PM, gobigdave <gobigdave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Just tried again with an environment of ''production'', and the same > thing happens -- a few clicks and memory grows to about 100M. Since I > will be moving my production environment anyway, I built a brand new > CentOS 5.1 slice (on SliceHost). I followed my original instructions > which involve building Ruby 1.8.6 from source and using yum and gem > for everything else. Within 5-6 page views mongrel_rails goes from > 50M to 98M. That does not happen on my current production server > (CentOS 5.0 on dedicated server at ServerBeach) -- after several > thousand page views the mongrel processes are still at 55M. > > It doesn''t feel like a leak to me because it levels off and stays > pretty steady. I think it''s the GC executing differently or something > to that affect, but I don''t remember doing anything different when I > built the original production server. At this point, I have two > machines running exactly the same application using exactly the same > rails config with VERY different memory usage. The only thing I can > think of is something with build args or libs on ruby because > everything else was done with yum and gem. I am assuming that yum and > gem will install exactly the same things on both machines. > > BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 > patchlevel 0) [x86_64-linux] > > What do most people see their mongrel_rails processes running at for > memory? Could I be looking at a difference in the way top reports > memory between CentOS 5.0 and 5.1? > > > On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > try them both on the same ''production'' -- if it still has the leak > > then there must be some either ''other'' variable or ''hidden'' variable > > in there somewhere [though I myself have used production and > > ''production2'' environment''s style before and it worked fine]. > > -R > > > > > > On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > No, I purposely setup the staging and production environments to be > > > the same. The log level is the same, all debug that I know of is > > > turned off in both systems, and caching is turned on. My previous > > > message had the environment file (exactly the same between the two), > > > and deploy.rb is only different in the ip addresses of the target > > > machines to install to. > > > > > Does Rails look at RAILS_ENV behind the scenes and do something > > > different? I''m aware of different defaults for logging level, but is > > > there something else? Trying to find good documentation on this stuff > > > is not easy (my only real problem with Rails in general). If so, then > > > I would be concerned since you want a staging environment to be as > > > close as possible to production as possible. I should be able to get > > > Rails to run as production when RAILS_ENV != ''production''. What if I > > > have two "production" environments (one is a backup)? > > > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > I think what he''s asking is if you are running the development system > > > > under development mode for your Rails application. Isn''t there a host > > > > of debugging and logging stuff going on in the background which could > > > > account for the increase in memory usage. > > > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Define production mode? They have different environments, but both > > > > > have the same setup. > > > > > > > config/staging.rb and config/production.rb are both: > > > > > > > require ''syslog_logger'' > > > > > > > # Settings specified here will take precedence over those in config/ > > > > > environment.rb > > > > > > > # The production environment is meant for finished, "live" apps. > > > > > # Code is not reloaded between requests > > > > > config.cache_classes = true > > > > > > > # Use a different logger for distributed setups > > > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > > > config.logger.level = Logger::INFO > > > > > > > # Full error reports are disabled and caching is turned on > > > > > config.action_controller.consider_all_requests_local = false > > > > > config.action_controller.perform_caching = true > > > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > are they both run in production mode? > > > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > > > different for each. > > > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > > > they start at around 50M memory, but within a few pages they are > > > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > > > memory on the prod system (148M). The test system will usually use it > > > > > > > all up and often begin swapping. > > > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > > > conserve memory. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Exact same databases in both places, and all servers were built from scratch. After some more digging, I''m think it may be that SliceHost uses 64bit distros for everything. I''m pretty sure my other two servers that don''t have this issue are 32bit. If that''s it, it seems kind of a waste to use 64bit in any of the smaller slices because you end up bloating all your processes. If you are only running 1Gig of RAM, there is no need for 64bit. I''m talking with the SliceHost folks right now. We''ll see what they have to say. If this turns out to be the issue, then their prices aren''t as good as they look because you have to get a larger slice to get the same performance. On my ServerBeach 1Gig machine, I can easily get 6 mongrels running and almost never swap. On my 512M slice, I can barely get 2 mongrels running before I start swapping. So, to get the same performance from a SliceHost server, I would need at least 2Gig slice, and that is a lot more than a 1Gig server at ServerBeach. On May 1, 12:41 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> did you build from scratch both places? > for me on ''big loads'' the mongrels stay at [sigh] about 120MB each. > > On Wed, Apr 30, 2008 at 9:59 PM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Just tried again with an environment of ''production'', and the same > > thing happens -- a few clicks and memory grows to about 100M. Since I > > will be moving my production environment anyway, I built a brand new > > CentOS 5.1 slice (on SliceHost). I followed my original instructions > > which involve building Ruby 1.8.6 from source and using yum and gem > > for everything else. Within 5-6 page views mongrel_rails goes from > > 50M to 98M. That does not happen on my current production server > > (CentOS 5.0 on dedicated server at ServerBeach) -- after several > > thousand page views the mongrel processes are still at 55M. > > > It doesn''t feel like a leak to me because it levels off and stays > > pretty steady. I think it''s the GC executing differently or something > > to that affect, but I don''t remember doing anything different when I > > built the original production server. At this point, I have two > > machines running exactly the same application using exactly the same > > rails config with VERY different memory usage. The only thing I can > > think of is something with build args or libs on ruby because > > everything else was done with yum and gem. I am assuming that yum and > > gem will install exactly the same things on both machines. > > > BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 > > patchlevel 0) [x86_64-linux] > > > What do most people see their mongrel_rails processes running at for > > memory? Could I be looking at a difference in the way top reports > > memory between CentOS 5.0 and 5.1? > > > On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > try them both on the same ''production'' -- if it still has the leak > > > then there must be some either ''other'' variable or ''hidden'' variable > > > in there somewhere [though I myself have used production and > > > ''production2'' environment''s style before and it worked fine]. > > > -R > > > > On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > No, I purposely setup the staging and production environments to be > > > > the same. The log level is the same, all debug that I know of is > > > > turned off in both systems, and caching is turned on. My previous > > > > message had the environment file (exactly the same between the two), > > > > and deploy.rb is only different in the ip addresses of the target > > > > machines to install to. > > > > > Does Rails look at RAILS_ENV behind the scenes and do something > > > > different? I''m aware of different defaults for logging level, but is > > > > there something else? Trying to find good documentation on this stuff > > > > is not easy (my only real problem with Rails in general). If so, then > > > > I would be concerned since you want a staging environment to be as > > > > close as possible to production as possible. I should be able to get > > > > Rails to run as production when RAILS_ENV != ''production''. What if I > > > > have two "production" environments (one is a backup)? > > > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I think what he''s asking is if you are running the development system > > > > > under development mode for your Rails application. Isn''t there a host > > > > > of debugging and logging stuff going on in the background which could > > > > > account for the increase in memory usage. > > > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Define production mode? They have different environments, but both > > > > > > have the same setup. > > > > > > > config/staging.rb and config/production.rb are both: > > > > > > > require ''syslog_logger'' > > > > > > > # Settings specified here will take precedence over those in config/ > > > > > > environment.rb > > > > > > > # The production environment is meant for finished, "live" apps. > > > > > > # Code is not reloaded between requests > > > > > > config.cache_classes = true > > > > > > > # Use a different logger for distributed setups > > > > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > > > > config.logger.level = Logger::INFO > > > > > > > # Full error reports are disabled and caching is turned on > > > > > > config.action_controller.consider_all_requests_local = false > > > > > > config.action_controller.perform_caching = true > > > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > are they both run in production mode? > > > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > > > > different for each. > > > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > > > > they start at around 50M memory, but within a few pages they are > > > > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > > > > memory on the prod system (148M). The test system will usually use it > > > > > > > > all up and often begin swapping. > > > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > > > > conserve memory.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Can anyone point me to a way to build ruby with the 32bit libraries on a 64bit distro? On my 4 servers, that seems to be the difference. The servers with the 32bit distro level off at < 60M per mongrel. The 64bit servers level off closer to 120M per mongrel. On a server with less than 2Gig of RAM, 64bit seems like a complete waste to me. Other than an ego trip, it doesn''t gain you anything because you don''t need the address space. On May 1, 2:44 pm, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Exact same databases in both places, and all servers were built from > scratch. After some more digging, I''m think it may be that SliceHost > uses 64bit distros for everything. I''m pretty sure my other two > servers that don''t have this issue are 32bit. If that''s it, it seems > kind of a waste to use 64bit in any of the smaller slices because you > end up bloating all your processes. If you are only running 1Gig of > RAM, there is no need for 64bit. > > I''m talking with the SliceHost folks right now. We''ll see what they > have to say. If this turns out to be the issue, then their prices > aren''t as good as they look because you have to get a larger slice to > get the same performance. On my ServerBeach 1Gig machine, I can easily > get 6 mongrels running and almost never swap. On my 512M slice, I can > barely get 2 mongrels running before I start swapping. So, to get the > same performance from a SliceHost server, I would need at least 2Gig > slice, and that is a lot more than a 1Gig server at ServerBeach. > > On May 1, 12:41 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > did you build from scratch both places? > > for me on ''big loads'' the mongrels stay at [sigh] about 120MB each. > > > On Wed, Apr 30, 2008 at 9:59 PM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Just tried again with an environment of ''production'', and the same > > > thing happens -- a few clicks and memory grows to about 100M. Since I > > > will be moving my production environment anyway, I built a brand new > > > CentOS 5.1 slice (on SliceHost). I followed my original instructions > > > which involve building Ruby 1.8.6 from source and using yum and gem > > > for everything else. Within 5-6 page views mongrel_rails goes from > > > 50M to 98M. That does not happen on my current production server > > > (CentOS 5.0 on dedicated server at ServerBeach) -- after several > > > thousand page views the mongrel processes are still at 55M. > > > > It doesn''t feel like a leak to me because it levels off and stays > > > pretty steady. I think it''s the GC executing differently or something > > > to that affect, but I don''t remember doing anything different when I > > > built the original production server. At this point, I have two > > > machines running exactly the same application using exactly the same > > > rails config with VERY different memory usage. The only thing I can > > > think of is something with build args or libs on ruby because > > > everything else was done with yum and gem. I am assuming that yum and > > > gem will install exactly the same things on both machines. > > > > BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 > > > patchlevel 0) [x86_64-linux] > > > > What do most people see their mongrel_rails processes running at for > > > memory? Could I be looking at a difference in the way top reports > > > memory between CentOS 5.0 and 5.1? > > > > On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > try them both on the same ''production'' -- if it still has the leak > > > > then there must be some either ''other'' variable or ''hidden'' variable > > > > in there somewhere [though I myself have used production and > > > > ''production2'' environment''s style before and it worked fine]. > > > > -R > > > > > On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > No, I purposely setup the staging and production environments to be > > > > > the same. The log level is the same, all debug that I know of is > > > > > turned off in both systems, and caching is turned on. My previous > > > > > message had the environment file (exactly the same between the two), > > > > > and deploy.rb is only different in the ip addresses of the target > > > > > machines to install to. > > > > > > Does Rails look at RAILS_ENV behind the scenes and do something > > > > > different? I''m aware of different defaults for logging level, but is > > > > > there something else? Trying to find good documentation on this stuff > > > > > is not easy (my only real problem with Rails in general). If so, then > > > > > I would be concerned since you want a staging environment to be as > > > > > close as possible to production as possible. I should be able to get > > > > > Rails to run as production when RAILS_ENV != ''production''. What if I > > > > > have two "production" environments (one is a backup)? > > > > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > I think what he''s asking is if you are running the development system > > > > > > under development mode for your Rails application. Isn''t there a host > > > > > > of debugging and logging stuff going on in the background which could > > > > > > account for the increase in memory usage. > > > > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Define production mode? They have different environments, but both > > > > > > > have the same setup. > > > > > > > > config/staging.rb and config/production.rb are both: > > > > > > > > require ''syslog_logger'' > > > > > > > > # Settings specified here will take precedence over those in config/ > > > > > > > environment.rb > > > > > > > > # The production environment is meant for finished, "live" apps. > > > > > > > # Code is not reloaded between requests > > > > > > > config.cache_classes = true > > > > > > > > # Use a different logger for distributed setups > > > > > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > > > > > config.logger.level = Logger::INFO > > > > > > > > # Full error reports are disabled and caching is turned on > > > > > > > config.action_controller.consider_all_requests_local = false > > > > > > > config.action_controller.perform_caching = true > > > > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > are they both run in production mode? > > > > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > > > > > different for each. > > > > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > > > > > they start at around 50M memory, but within a few pages they are > > > > > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > > > > > memory on the prod system (148M). The test system will usually use it > > > > > > > > > all up and often begin swapping. > > > > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > > > > > conserve memory.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
you may be able to used a fixed heap chunk size to enable it to reclaim more of the memory and return it to the OS. [i.e. tweaking the GC to make it better]. Maybe :) -R On Thu, May 1, 2008 at 3:51 PM, gobigdave <gobigdave-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Can anyone point me to a way to build ruby with the 32bit libraries on > a 64bit distro? On my 4 servers, that seems to be the difference. The > servers with the 32bit distro level off at < 60M per mongrel. The > 64bit servers level off closer to 120M per mongrel. On a server with > less than 2Gig of RAM, 64bit seems like a complete waste to me. Other > than an ego trip, it doesn''t gain you anything because you don''t need > the address space.May want to ask slicehost about it.> > > > On May 1, 2:44 pm, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Exact same databases in both places, and all servers were built from > > scratch. After some more digging, I''m think it may be that SliceHost > > uses 64bit distros for everything. I''m pretty sure my other two > > servers that don''t have this issue are 32bit. If that''s it, it seems > > kind of a waste to use 64bit in any of the smaller slices because you > > end up bloating all your processes. If you are only running 1Gig of > > RAM, there is no need for 64bit. > > > > I''m talking with the SliceHost folks right now. We''ll see what they > > have to say. If this turns out to be the issue, then their prices > > aren''t as good as they look because you have to get a larger slice to > > get the same performance. On my ServerBeach 1Gig machine, I can easily > > get 6 mongrels running and almost never swap. On my 512M slice, I can > > barely get 2 mongrels running before I start swapping. So, to get the > > same performance from a SliceHost server, I would need at least 2Gig > > slice, and that is a lot more than a 1Gig server at ServerBeach. > > > > On May 1, 12:41 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > did you build from scratch both places? > > > for me on ''big loads'' the mongrels stay at [sigh] about 120MB each. > > > > > On Wed, Apr 30, 2008 at 9:59 PM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Just tried again with an environment of ''production'', and the same > > > > thing happens -- a few clicks and memory grows to about 100M. Since I > > > > will be moving my production environment anyway, I built a brand new > > > > CentOS 5.1 slice (on SliceHost). I followed my original instructions > > > > which involve building Ruby 1.8.6 from source and using yum and gem > > > > for everything else. Within 5-6 page views mongrel_rails goes from > > > > 50M to 98M. That does not happen on my current production server > > > > (CentOS 5.0 on dedicated server at ServerBeach) -- after several > > > > thousand page views the mongrel processes are still at 55M. > > > > > > It doesn''t feel like a leak to me because it levels off and stays > > > > pretty steady. I think it''s the GC executing differently or something > > > > to that affect, but I don''t remember doing anything different when I > > > > built the original production server. At this point, I have two > > > > machines running exactly the same application using exactly the same > > > > rails config with VERY different memory usage. The only thing I can > > > > think of is something with build args or libs on ruby because > > > > everything else was done with yum and gem. I am assuming that yum and > > > > gem will install exactly the same things on both machines. > > > > > > BTW, ruby -v on both systems returns: ruby 1.8.6 (2007-03-13 > > > > patchlevel 0) [x86_64-linux] > > > > > > What do most people see their mongrel_rails processes running at for > > > > memory? Could I be looking at a difference in the way top reports > > > > memory between CentOS 5.0 and 5.1? > > > > > > On Apr 30, 5:50 pm, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > try them both on the same ''production'' -- if it still has the leak > > > > > then there must be some either ''other'' variable or ''hidden'' variable > > > > > in there somewhere [though I myself have used production and > > > > > ''production2'' environment''s style before and it worked fine]. > > > > > -R > > > > > > > On Wed, Apr 30, 2008 at 11:21 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > No, I purposely setup the staging and production environments to be > > > > > > the same. The log level is the same, all debug that I know of is > > > > > > turned off in both systems, and caching is turned on. My previous > > > > > > message had the environment file (exactly the same between the two), > > > > > > and deploy.rb is only different in the ip addresses of the target > > > > > > machines to install to. > > > > > > > > Does Rails look at RAILS_ENV behind the scenes and do something > > > > > > different? I''m aware of different defaults for logging level, but is > > > > > > there something else? Trying to find good documentation on this stuff > > > > > > is not easy (my only real problem with Rails in general). If so, then > > > > > > I would be concerned since you want a staging environment to be as > > > > > > close as possible to production as possible. I should be able to get > > > > > > Rails to run as production when RAILS_ENV != ''production''. What if I > > > > > > have two "production" environments (one is a backup)? > > > > > > > > On Apr 30, 1:00 pm, Bobnation <boblmart...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > I think what he''s asking is if you are running the development system > > > > > > > under development mode for your Rails application. Isn''t there a host > > > > > > > of debugging and logging stuff going on in the background which could > > > > > > > account for the increase in memory usage. > > > > > > > > > On Apr 30, 10:12 am, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > Define production mode? They have different environments, but both > > > > > > > > have the same setup. > > > > > > > > > > config/staging.rb and config/production.rb are both: > > > > > > > > > > require ''syslog_logger'' > > > > > > > > > > # Settings specified here will take precedence over those in config/ > > > > > > > > environment.rb > > > > > > > > > > # The production environment is meant for finished, "live" apps. > > > > > > > > # Code is not reloaded between requests > > > > > > > > config.cache_classes = true > > > > > > > > > > # Use a different logger for distributed setups > > > > > > > > config.logger = RAILS_DEFAULT_LOGGER = SyslogLogger.new(''msc'') > > > > > > > > config.logger.level = Logger::INFO > > > > > > > > > > # Full error reports are disabled and caching is turned on > > > > > > > > config.action_controller.consider_all_requests_local = false > > > > > > > > config.action_controller.perform_caching = true > > > > > > > > > > On Apr 30, 11:03 am, "Roger Pack" <rogerpack2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > are they both run in production mode? > > > > > > > > > > > On Wed, Apr 30, 2008 at 8:45 AM, gobigdave <gobigd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > Like most, I have a test and a production env. Both are CentOS 5, Ruby > > > > > > > > > > 1.8.6, Rails 2.0.2, MySQL 5, and Apache. Both were setup using the > > > > > > > > > > same procedure. Except for the hardware (test: Intel, prod: AMD) and > > > > > > > > > > memory (test: 512M, prod: 1G), both systems are essentially the same > > > > > > > > > > right down to the Rails env. Unfortunately, memory usage is very > > > > > > > > > > different for each. > > > > > > > > > > > > The test system has 2 mongrel instances running. According to top, > > > > > > > > > > they start at around 50M memory, but within a few pages they are > > > > > > > > > > quickly up to 100M. The production systems have 5 mongrels, and they > > > > > > > > > > start at around 50M as well. However, hit them with thousands of page > > > > > > > > > > views and their memory usage rarely passes 60M. It''s almost as if the > > > > > > > > > > GC isn''t running on the test system. There is still plenty of free > > > > > > > > > > memory on the prod system (148M). The test system will usually use it > > > > > > > > > > all up and often begin swapping. > > > > > > > > > > > > Any thoughts? Any ideas where I might look? I prefer to not even pay > > > > > > > > > > for the 512M VM for the test system, but it doesn''t seem to want to > > > > > > > > > > conserve memory. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
>> Can anyone point me to a way to build ruby with the 32bit libraries on >> a 64bit distro? On my 4 servers, that seems to be the difference. The >> servers with the 32bit distro level off at < 60M per mongrel. The >> 64bit servers level off closer to 120M per mongrel. On a server with >> less than 2Gig of RAM, 64bit seems like a complete waste to me. Other >> than an ego trip, it doesn''t gain you anything because you don''t need >> the address space.You could also try to reduce memory usage pennysmalls.com or what not. -R -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---