We are seeing memory leaks with Rails under the following circumstances... Apache/FastCGI Lighttpd/FastCGI Webrick Memory is never released. We did a simple test controller where all it did was render_text( "Hello World" ). We did this so we could determine if it was our code, or rails code. It appears to be leaking with rails code. I also had set ActionController::Base.perform_caching = false We have seen this problem with Rails 0.12.1 and 0.13.1. Also, as reqeusts increase response times drastically reduce. I tested an upload of 1,703 8Kb files. I uploaded them in blocks of 40 files. Initially I could get 40 uploaded in a matter of 8-12 seconds. But as I got around the 200th file speed was cut in half, and then by the 500th upload it was cut in half again. Eventually in started taking 100+ seconds to upload 40 8Kb files. Any insight, help or assistance on this would be great. Thanks, Zach
Memory leaks in development environment are a known issue. Make sure to perform your tests in production environment. On 8/4/05, Zach Dennis <zdennis-aRAREQmnvsAAvxtiuMwx3w@public.gmane.org> wrote:> We are seeing memory leaks with Rails under the following circumstances... > > Apache/FastCGI > Lighttpd/FastCGI > Webrick > > Memory is never released. We did a simple test controller where all it > did was render_text( "Hello World" ). We did this so we could determine > if it was our code, or rails code. It appears to be leaking with rails code. > > I also had set ActionController::Base.perform_caching = false > > We have seen this problem with Rails 0.12.1 and 0.13.1. Also, as > reqeusts increase response times drastically reduce. > > I tested an upload of 1,703 8Kb files. I uploaded them in blocks of 40 > files. > > Initially I could get 40 uploaded in a matter of 8-12 seconds. But as I > got around the 200th file speed was cut in half, and then by the 500th > upload it was cut in half again. Eventually in started taking 100+ > seconds to upload 40 8Kb files. > > Any insight, help or assistance on this would be great. Thanks, > > Zach > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
I''m sorry, but can you clarify that statement Tobias? It would seem logical to me that the object of testing in a development environment is to catch these issues before you deploy into production where it might have ill effect to your customer/user base. If dev tests signify that there may be a problem, then wouldn''t it stand that the same problem will exist in production, which ideally (given a good testing environment) would simply be a reproduction of your testing environment, just available for public consumption? I may be completely missing your point, of course, but I am interested in your distinction. D''Andrew On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Memory leaks in development environment are a known issue. Make sure > to perform your tests in production environment. > > On 8/4/05, Zach Dennis <zdennis-aRAREQmnvsAAvxtiuMwx3w@public.gmane.org> wrote: > > We are seeing memory leaks with Rails under the following circumstances... > > > > Apache/FastCGI > > Lighttpd/FastCGI > > Webrick > > > > Memory is never released. We did a simple test controller where all it > > did was render_text( "Hello World" ). We did this so we could determine > > if it was our code, or rails code. It appears to be leaking with rails code. > > > > I also had set ActionController::Base.perform_caching = false > > > > We have seen this problem with Rails 0.12.1 and 0.13.1. Also, as > > reqeusts increase response times drastically reduce. > > > > I tested an upload of 1,703 8Kb files. I uploaded them in blocks of 40 > > files. > > > > Initially I could get 40 uploaded in a matter of 8-12 seconds. But as I > > got around the 200th file speed was cut in half, and then by the 500th > > upload it was cut in half again. Eventually in started taking 100+ > > seconds to upload 40 8Kb files. > > > > Any insight, help or assistance on this would be great. Thanks, > > > > Zach > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > Tobi > http://www.snowdevil.ca - Snowboards that don''t suck > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- ~~~~~~~~~~~~~~~~~~~ D''Andrew Thompson http://dathompson.blogspot.com
Tobias Luetke wrote:> Memory leaks in development environment are a known issue. Make sure > to perform your tests in production environment. >We tested in both development and production mode. Zach
Known issue == known bug :) Am 04.08.2005 um 20:29 schrieb D''Andrew Thompson:> I''m sorry, but can you clarify that statement Tobias? > > It would seem logical to me that the object of testing in a > development environment is to catch these issues before you deploy > into production where it might have ill effect to your customer/user > base. > > If dev tests signify that there may be a problem, then wouldn''t it > stand that the same problem will exist in production, which ideally > (given a good testing environment) would simply be a reproduction of > your testing environment, just available for public consumption? > > I may be completely missing your point, of course, but I am interested > in your distinction. > > D''Andrew > > On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Memory leaks in development environment are a known issue. Make sure >> to perform your tests in production environment. >>
On Thursday 04 August 2005 20:29, D''Andrew Thompson wrote:> I''m sorry, but can you clarify that statement Tobias? > > It would seem logical to me that the object of testing in a > development environment is to catch these issues before you deploy > into production where it might have ill effect to your customer/user > base. > > If dev tests signify that there may be a problem, then wouldn''t it > stand that the same problem will exist in production, which ideally > (given a good testing environment) would simply be a reproduction of > your testing environment, just available for public consumption? > > I may be completely missing your point, of course, but I am > interested in your distinction.You''re missing the distinction between Rails environments and deployment environments. When running a Rails app, you''ve got the choice between development and production environment. In the former, changes to code are immediately effective, in the latter they''re not; additionally, in the production environment caching is enabled. Now, in which of these "environments" you run your app is just a matter of a switch. When you run script/server without any options, it runs in the development environment. When you run script/server -e production, it runs in the production environment. That''s all. So to stress test your app and watch its memory usage you might want to run it in the Rails production environment. Michael -- Michael Schuerig The more it stays the same, mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org The less it changes! http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock
I think Tobias means that when rails is in development mode, i.e RAILS_ENV = development, there are memory issues. Not because of your rails application, but because while in dev mode, there''s more internal things going on such as logging, more sql statements, etc. It''s a known issue and I''m pretty sure it will be addressed soon. With that said, you should test your app in production to see if the leak is indeed your application. Jin On 8/4/05, Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote:> > Known issue == known bug :) > > Am 04.08.2005 um 20:29 schrieb D''Andrew Thompson: > > > I''m sorry, but can you clarify that statement Tobias? > > > > It would seem logical to me that the object of testing in a > > development environment is to catch these issues before you deploy > > into production where it might have ill effect to your customer/user > > base. > > > > If dev tests signify that there may be a problem, then wouldn''t it > > stand that the same problem will exist in production, which ideally > > (given a good testing environment) would simply be a reproduction of > > your testing environment, just available for public consumption? > > > > I may be completely missing your point, of course, but I am interested > > in your distinction. > > > > D''Andrew > > > > On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > >> Memory leaks in development environment are a known issue. Make sure > >> to perform your tests in production environment. > >> > _______________________________________________ > 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
Thank you for the clarifications. Where can I find documentation on the specific/detailed differences between production/dev/test. Namely, what routines are different, what is turned off/on, etc. D''Andrew On 8/4/05, Jin Lee <jinslee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I think Tobias means that when rails is in development mode, i.e RAILS_ENV > development, there are memory issues. Not because of your rails application, > but because while in dev mode, there''s more internal things going on such as > logging, more sql statements, etc. It''s a known issue and I''m pretty sure it > will be addressed soon. With that said, you should test your app in > production to see if the leak is indeed your application. > > Jin > > > On 8/4/05, Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote: > > > > Known issue == known bug :) > > > > Am 04.08.2005 um 20:29 schrieb D''Andrew Thompson: > > > > > I''m sorry, but can you clarify that statement Tobias? > > > > > > It would seem logical to me that the object of testing in a > > > development environment is to catch these issues before you deploy > > > into production where it might have ill effect to your customer/user > > > base. > > > > > > If dev tests signify that there may be a problem, then wouldn''t it > > > stand that the same problem will exist in production, which ideally > > > (given a good testing environment) would simply be a reproduction of > > > your testing environment, just available for public consumption? > > > > > > I may be completely missing your point, of course, but I am interested > > > in your distinction. > > > > > > D''Andrew > > > > > > On 8/4/05, Tobias Luetke < tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > >> Memory leaks in development environment are a known issue. Make sure > > >> to perform your tests in production environment. > > >> > > _______________________________________________ > > 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 > > >-- ~~~~~~~~~~~~~~~~~~~ D''Andrew Thompson http://dathompson.blogspot.com
the files in config/environment.rb are the only difference. You can lookup the documentation for the switches used there. On 8/4/05, D''Andrew Thompson <dandrew.thompson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Thank you for the clarifications. Where can I find documentation on > the specific/detailed differences between production/dev/test. Namely, > what routines are different, what is turned off/on, etc. > > D''Andrew > > On 8/4/05, Jin Lee <jinslee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I think Tobias means that when rails is in development mode, i.e RAILS_ENV > > development, there are memory issues. Not because of your rails application, > > but because while in dev mode, there''s more internal things going on such as > > logging, more sql statements, etc. It''s a known issue and I''m pretty sure it > > will be addressed soon. With that said, you should test your app in > > production to see if the leak is indeed your application. > > > > Jin > > > > > > On 8/4/05, Thomas Fuchs <thomas-9D208sng4xU@public.gmane.org> wrote: > > > > > > Known issue == known bug :) > > > > > > Am 04.08.2005 um 20:29 schrieb D''Andrew Thompson: > > > > > > > I''m sorry, but can you clarify that statement Tobias? > > > > > > > > It would seem logical to me that the object of testing in a > > > > development environment is to catch these issues before you deploy > > > > into production where it might have ill effect to your customer/user > > > > base. > > > > > > > > If dev tests signify that there may be a problem, then wouldn''t it > > > > stand that the same problem will exist in production, which ideally > > > > (given a good testing environment) would simply be a reproduction of > > > > your testing environment, just available for public consumption? > > > > > > > > I may be completely missing your point, of course, but I am interested > > > > in your distinction. > > > > > > > > D''Andrew > > > > > > > > On 8/4/05, Tobias Luetke < tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > >> Memory leaks in development environment are a known issue. Make sure > > > >> to perform your tests in production environment. > > > >> > > > _______________________________________________ > > > 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 > > > > > > > > > -- > ~~~~~~~~~~~~~~~~~~~ > D''Andrew Thompson > http://dathompson.blogspot.com > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
<lots snipped> The last patch on http://dev.rubyonrails.com/ticket/1704 should fix the memory leak in dev mode in webrick once and for all. There is still a problem with lighttpd / fastcgi and dev mode which I''m going to look at over the weekend. Cheers, Chris