I''m having a huge memory leak problem with a rails application I''m developing! I first noticed that when running under webrick (via script/server) there was a fast memory leak.. several users using the app for a few hours would use 2 gig of memory!!! I searched the archives and found that some users found that it could be avoided by saying --daemon when launching webrick.. tried: no luck. I then deployed via fastcgi on apache2.. No luck... So it''s not webrick.. and likely not fastcgi either.. that leaves rails itself.. But how can there be a memory leak in a garbage collected language?? It''s running on SUSE 9.1 on ruby 1.8.2 that was compiled from sources (suse package is only 1.8.1). I really need to work this through.. the only option I have left is hoping that a raw CGI will be fine because it will reload everything with every request.. hopefully that would avoid the leak but I realize how bad the performance would be in that environment. Thanks in advance!
aha!! That would explain it!! I am running in development mode. I wonder if there shouldn''t be a warning or something when you start in development mode?.. I''ve been pulling my hair out with worry!!! :) Thanks again!! Then: onto my next question.. I''m happy to continue using webrick for development, and fastcgi for production.. so: what is the most elegant way of having fastcgi run in production mode? With webrick it''s easy (just launch with -e yadayda).. but I haven''t found anything for fastcgi.. and: I''ve been getting "Dispatcher failed to catch: Session contained objects where the class definition wasn''t available. Remember to require classes for all objects kept in the session. The session has been deleted." messages under fastcgi.. Is that related to the development mode as well? On Saturday 14 May 2005 18:10, Matt Jankowski wrote:> are you in development or production mode? > > There''s an actual memory leak in the non-latest version of ruby-fcgi -- > but there''s also an accepted memory-leak-over-time policy w/ development > mode. Try switching to production mode and stress-testing. > > Luke Galea wrote: > > I''m having a huge memory leak problem with a rails application I''m > > developing! > > > > I first noticed that when running under webrick (via script/server) there > > was a fast memory leak.. several users using the app for a few hours > > would use 2 gig of memory!!! > > > > I searched the archives and found that some users found that it could be > > avoided by saying --daemon when launching webrick.. tried: no luck. > > > > I then deployed via fastcgi on apache2.. No luck... So it''s not webrick.. > > and likely not fastcgi either.. that leaves rails itself.. > > > > But how can there be a memory leak in a garbage collected language?? > > > > It''s running on SUSE 9.1 on ruby 1.8.2 that was compiled from sources > > (suse package is only 1.8.1). > > > > I really need to work this through.. the only option I have left is > > hoping that a raw CGI will be fine because it will reload everything with > > every request.. hopefully that would avoid the leak but I realize how bad > > the performance would be in that environment. > > > > Thanks in advance! > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
are you in development or production mode? There''s an actual memory leak in the non-latest version of ruby-fcgi -- but there''s also an accepted memory-leak-over-time policy w/ development mode. Try switching to production mode and stress-testing. Luke Galea wrote:> I''m having a huge memory leak problem with a rails application I''m developing! > > I first noticed that when running under webrick (via script/server) there was > a fast memory leak.. several users using the app for a few hours would use 2 > gig of memory!!! > > I searched the archives and found that some users found that it could be > avoided by saying --daemon when launching webrick.. tried: no luck. > > I then deployed via fastcgi on apache2.. No luck... So it''s not webrick.. and > likely not fastcgi either.. that leaves rails itself.. > > But how can there be a memory leak in a garbage collected language?? > > It''s running on SUSE 9.1 on ruby 1.8.2 that was compiled from sources (suse > package is only 1.8.1). > > I really need to work this through.. the only option I have left is hoping > that a raw CGI will be fine because it will reload everything with every > request.. hopefully that would avoid the leak but I realize how bad the > performance would be in that environment. > > Thanks in advance! > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 5/14/05, Luke Galea <luke.galea-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> wrote:> Then: onto my next question.. I''m happy to continue using webrick for > development, and fastcgi for production..That''s what I do.> so: what is the most elegant way of > having fastcgi run in production mode? With webrick it''s easy (just launch > with -e yadayda).. but I haven''t found anything for fastcgi..In dispatch.fcgi: ENV[''RAILS_ENV'']="production" Now your fastcgi will set the environment to production, but webrick will still default to development because it doesn''t load the dispatch.fcgi file and doesn''t get the variable set to production. -- Urban Artography http://artography.ath.cx
> Then: onto my next question.. I''m happy to continue using webrick for > development, and fastcgi for production.. so: what is the most elegant way of > having fastcgi run in production mode? With webrick it''s easy (just launch > with -e yadayda).. but I haven''t found anything for fastcgi..If you use Lighttpd to run your Rails apps (which you should. no really =), then you can specify the following (I''ve taken the relevant part out of my config file): fastcgi.server = ( ".fcgi" => ("rails" => ( "socket" => "/path/to/rails/app/lighttpd-fcgi.socket", "bin-path" => "/path/to/rails/app/public/dispatch.fcgi", "bin-environment" => ("RAILS_ENV" => "production"), "min-procs" => 1, "max-procs" => 5 ) ) ) Under bin-environment you can also sent any other environment variables if you need to. HTH
On 15.5.2005, at 09:52, Luke Randall wrote:> > > fastcgi.server = ( ".fcgi" => > ("rails" => > ( "socket" => > "/path/to/rails/app/lighttpd-fcgi.socket", > "bin-path" => > "/path/to/rails/app/public/dispatch.fcgi", > "bin-environment" => ("RAILS_ENV" > => "production"), > "min-procs" => 1, > "max-procs" => 5 > ) > ) > )Just FYI, setting min-procs and max-procs to the same value improves performance reportedly. I have them both set to 5 at the moment. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 14.5.2005, at 21:21, Luke Galea wrote:> and: I''ve been getting "Dispatcher failed to catch: Session contained > objects > where the class definition wasn''t available. Remember to require > classes for > all objects kept in the session. The session has been deleted." > messages > under fastcgi.. Is that related to the development mode as well?Not necessarily. You might have changed your app but the session files still have objects that you don''t have a definition for. Removing the session files probably helps. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails