I''m researching Rails deployment, anyway, so I''ll do some poking around. Alex On 3/7/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> > I''ve been getting a bunch of reports about the latest Rails "leaking" > memory more than before. Please fill out this survey: > > 1) Have you noticed an increase in memory usage with the latest Rails > 1.2? > > 2) Have you changed anything else in your application? > > a) No, really, don''t be a dumbass like the lusers you hate. Go look > at your svn logs and really figure out if you''ve changed anything else. > > 3) I ask again, did you change anything else since as well as Rails 1.2? > > 4) Does going back to a previous Rails (if you can) get rid of the > memory leak? > > 5) Have you tried taking a basic controller that renders :text => > "test" only and run sequential hits against it? > > a) Does the ram increase? > > b) If not, have run this same test against a page that does? > > c) What''s the difference between the leaking and non-leaking page? > > 6) Do you have this problem with FastCGI? > > 7) Do you have this problem if you add a GC.start call to the end of > your leaking requests, or as an after filter in a strategic location? > > Thanks, please keep the response short so I can start looking for > patterns. > > In my tests I''m not finding any leaks so I need more information. > Reproducible processes and sample code will really help a lot. > > -- > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu > http://www.zedshaw.com/ > http://www.awprofessional.com/title/0321483502 -- The Mongrel Book > http://mongrel.rubyforge.org/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070307/dff20a3a/attachment.html
I''ve been getting a bunch of reports about the latest Rails "leaking" memory more than before. Please fill out this survey: 1) Have you noticed an increase in memory usage with the latest Rails 1.2? 2) Have you changed anything else in your application? a) No, really, don''t be a dumbass like the lusers you hate. Go look at your svn logs and really figure out if you''ve changed anything else. 3) I ask again, did you change anything else since as well as Rails 1.2? 4) Does going back to a previous Rails (if you can) get rid of the memory leak? 5) Have you tried taking a basic controller that renders :text => "test" only and run sequential hits against it? a) Does the ram increase? b) If not, have run this same test against a page that does? c) What''s the difference between the leaking and non-leaking page? 6) Do you have this problem with FastCGI? 7) Do you have this problem if you add a GC.start call to the end of your leaking requests, or as an after filter in a strategic location? Thanks, please keep the response short so I can start looking for patterns. In my tests I''m not finding any leaks so I need more information. Reproducible processes and sample code will really help a lot. -- 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/
When I switched to rails 1.2 I noticed a large decrease in memory usage. However, this is probably because I 1) switched from mysql to postgresql and 2) stopped using acts_as_ferret. Currently, my 3 mongrel processes are running strong. They''ve currently been up for 3 days and the memory is at 67MB, 65MB, and 59MB. -carl
Zed A. Shaw wrote:> I''ve been getting a bunch of reports about the latest Rails "leaking" > memory more than before. Please fill out this survey: > > 1) Have you noticed an increase in memory usage with the latest Rails > 1.2? > > 2) Have you changed anything else in your application? > > a) No, really, don''t be a dumbass like the lusers you hate. Go look > at your svn logs and really figure out if you''ve changed anything else. > > 3) I ask again, did you change anything else since as well as Rails 1.2? > > 4) Does going back to a previous Rails (if you can) get rid of the > memory leak? > > 5) Have you tried taking a basic controller that renders :text => > "test" only and run sequential hits against it? > > a) Does the ram increase? > > b) If not, have run this same test against a page that does? > > c) What''s the difference between the leaking and non-leaking page? > > 6) Do you have this problem with FastCGI? > > 7) Do you have this problem if you add a GC.start call to the end of > your leaking requests, or as an after filter in a strategic location? > > Thanks, please keep the response short so I can start looking for > patterns. > > In my tests I''m not finding any leaks so I need more information. > Reproducible processes and sample code will really help a lot. > >No apparent leaks here. I even hammered it with httperf just to double-check. I''m running Rails 1.2.1 and Mongrel 1.0.1. My processes grow to about 60-70 MB then stabilize. The processes do randomly die on occasion, but monit to restarts them when necessary. -- Jack Christensen jackc at hylesanderson.edu
I''ve got a completely reproducable case, but it has nothing to do with Mongrel. When I use the file_column plugin [1] and resize images with rmagick, every Mongrel/fcgi process grows in size until it reaches it''s limit (my fcgi processes are limited to 100 MB). Once there, they will block/sleep/whatever and get swapped out by the OS. Eventually swap is exhausted and carnage ensues. Without RMagick this does not happen at all, processes are 34-40 MB and that''s including acts_as_ferret. This behaviour has definitely become more apparent since 1.2 though. And to make life more interesting I''ve changed all parameters outside the application: new mysql, new ruby, new webserver, a bunch of plugins and moving towards resources-based routing. So can''t help you (or myself) there. [1] http://www.kanthak.net/opensource/file_column/ i know, it''s ancient. Op 7-mrt-2007, om 20:49 heeft Zed A. Shaw het volgende geschreven:> I''ve been getting a bunch of reports about the latest Rails "leaking" > memory more than before. Please fill out this survey: > > 1) Have you noticed an increase in memory usage with the latest Rails > 1.2? > > 2) Have you changed anything else in your application? > > a) No, really, don''t be a dumbass like the lusers you hate. Go look > at your svn logs and really figure out if you''ve changed anything > else. > > 3) I ask again, did you change anything else since as well as Rails > 1.2? > > 4) Does going back to a previous Rails (if you can) get rid of the > memory leak? > > 5) Have you tried taking a basic controller that renders :text => > "test" only and run sequential hits against it? > > a) Does the ram increase? > > b) If not, have run this same test against a page that does? > > c) What''s the difference between the leaking and non-leaking page? > > 6) Do you have this problem with FastCGI? > > 7) Do you have this problem if you add a GC.start call to the end of > your leaking requests, or as an after filter in a strategic location? > > Thanks, please keep the response short so I can start looking for > patterns. > > In my tests I''m not finding any leaks so I need more information. > Reproducible processes and sample code will really help a lot. > > -- > Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu > http://www.zedshaw.com/ > http://www.awprofessional.com/title/0321483502 -- The Mongrel Book > http://mongrel.rubyforge.org/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users-- www.gomagazine.nl +31643904460 pobox 51059 nl-1007eb amsterdam -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2423 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/97b447e7/attachment.bin
On 8.3.2007, at 1.40, joost baaij wrote:> I''ve got a completely reproducable case, but it has nothing to do > with Mongrel. > > When I use the file_column plugin [1] and resize images with > rmagick, every Mongrel/fcgi process grows in size until it reaches > it''s limit (my fcgi processes are limited to 100 MB). Once there, > they will block/sleep/whatever and get swapped out by the OS. > Eventually swap is exhausted and carnage ensues. > > Without RMagick this does not happen at all, processes are 34-40 MB > and that''s including acts_as_ferret. This behaviour has definitely > become more apparent since 1.2 though. And to make life more > interesting I''ve changed all parameters outside the application: > new mysql, new ruby, new webserver, a bunch of plugins and moving > towards resources-based routing. So can''t help you (or myself) there. >It''s a known fact that RMagick can leak like a sieve in Rails (explanation here [1]). You might want to try out minimagick [2] or imagescience [3] instead if you can. [1] http://codehappy.wordpress.com/2007/01/17/tracking-a-memory-leak- in-rails/ [2] http://rubyforge.org/projects/mini-magick/ [3] http://seattlerb.rubyforge.org/ImageScience.html -- Jarkko Laine http://jlaine.net http://dotherightthing.com http://www.railsecommerce.com http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070308/36f003a7/attachment.bin