Previously posted on ruby talk. Response...silence :)
......
Perhaps someone out there can help give me a clue about the following
situation:
My mongrel processes seemed to be leaking.
As an example of this, if I added this code to the bottom of
environment.rb
Thread.new {loop do; print ''w''; end}
it didn''t affect memory. At first. However after the web server got
its
first hit its memory consumption would sky-rocket. [i.e. it would
monotonically grow by about 50MB/s]
Then I ran the same scenario using webrick, instead of mongrel [1.1.3].
No leak.
Then I''m thinking ''hmm maybe it''s mongrel and the
mongrel guys have
fixed this.''
Update my gem to 1.1.4 from 1.1.3.
Using mongrel this time.
No leak! Yea!
Now this is the weird part.
Attempted to recreate the bug.
Uninstalled mongrel 1.1.4, reinstalled 1.1.3
uninstalled daemons [its dependency] 1.0.10, reinstalled 1.0.9 [what I
had before].
Ran it with Mongrel again [which is where it used to leak].
No leak.
I am so confused!
Perhaps rubygems was updated and so it "compiled it right this time"?
Note that there don''t appear to be significant code changes in mongrel
from 1.1.3 to 1.1.4, though there could be, I''m not sure.
It''s probably
not even a mongrel problem.
Maybe if somebody else who ''suspects'' a memory leak could try
my code
and see if it leaks theirs, that would be well appreciated.
The good news is that "maybe" updating rubygems and recompiling
mongrel
helps with memory leaks in rails apps.
Thoughts?
-R
OS X PPC patchlevel 111
--
Posted via http://www.ruby-forum.com/.
Maybe the upgrade installed fastthread? Most likely though it''s related to the Rails app itself, not Mongrel, and isn''t immediately reproducible. Cache freshness could have a large effect on which codepaths get traversed. What did you add that Thread loop for? I don''t understand. Evan On Mon, Apr 28, 2008 at 4:14 PM, Roger Pack <lists at ruby-forum.com> wrote:> Previously posted on ruby talk. Response...silence :) > > ...... > Perhaps someone out there can help give me a clue about the following > situation: > > My mongrel processes seemed to be leaking. > As an example of this, if I added this code to the bottom of > environment.rb > Thread.new {loop do; print ''w''; end} > it didn''t affect memory. At first. However after the web server got > its > first hit its memory consumption would sky-rocket. [i.e. it would > monotonically grow by about 50MB/s] > > Then I ran the same scenario using webrick, instead of mongrel [1.1.3]. > No leak. > > Then I''m thinking ''hmm maybe it''s mongrel and the mongrel guys have > fixed this.'' > > Update my gem to 1.1.4 from 1.1.3. > Using mongrel this time. > No leak! Yea! > > Now this is the weird part. > Attempted to recreate the bug. > Uninstalled mongrel 1.1.4, reinstalled 1.1.3 > uninstalled daemons [its dependency] 1.0.10, reinstalled 1.0.9 [what I > had before]. > > Ran it with Mongrel again [which is where it used to leak]. > No leak. > I am so confused! > Perhaps rubygems was updated and so it "compiled it right this time"? > Note that there don''t appear to be significant code changes in mongrel > from 1.1.3 to 1.1.4, though there could be, I''m not sure. It''s probably > not even a mongrel problem. > > Maybe if somebody else who ''suspects'' a memory leak could try my code > and see if it leaks theirs, that would be well appreciated. > > The good news is that "maybe" updating rubygems and recompiling mongrel > helps with memory leaks in rails apps. > > Thoughts? > -R > OS X PPC patchlevel 111 > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Evan Weaver
On Mon, Apr 28, 2008 at 5:14 PM, Roger Pack <lists at ruby-forum.com> wrote:> Previously posted on ruby talk. Response...silence :) >Didn''t saw that post, sorry.> ...... > Perhaps someone out there can help give me a clue about the following > situation: > > My mongrel processes seemed to be leaking. > As an example of this, if I added this code to the bottom of > environment.rb > Thread.new {loop do; print ''w''; end} > it didn''t affect memory. At first. However after the web server got > its > first hit its memory consumption would sky-rocket. [i.e. it would > monotonically grow by about 50MB/s] > > Then I ran the same scenario using webrick, instead of mongrel [1.1.3]. > No leak. > > Then I''m thinking ''hmm maybe it''s mongrel and the mongrel guys have > fixed this.'' > > Update my gem to 1.1.4 from 1.1.3. > Using mongrel this time. > No leak! Yea! > > Now this is the weird part. > Attempted to recreate the bug. > Uninstalled mongrel 1.1.4, reinstalled 1.1.3 > uninstalled daemons [its dependency] 1.0.10, reinstalled 1.0.9 [what I > had before]. > > Ran it with Mongrel again [which is where it used to leak]. > No leak. > I am so confused! > Perhaps rubygems was updated and so it "compiled it right this time"? > Note that there don''t appear to be significant code changes in mongrel > from 1.1.3 to 1.1.4, though there could be, I''m not sure. It''s probably > not even a mongrel problem. > > Maybe if somebody else who ''suspects'' a memory leak could try my code > and see if it leaks theirs, that would be well appreciated. > > The good news is that "maybe" updating rubygems and recompiling mongrel > helps with memory leaks in rails apps. > > Thoughts? > -R > OS X PPC patchlevel 111Did you upgraded rubygems at the time you updated mongrel from 1.1.3 to 1.1.4? Also, did you hit the same request/url during testing and recreating this bug? (just to be sure). I''ve seen lot of complains about "my mongrel is eating my memory", but as Erza commented in his Rack Rails [1], it seems lot of stuff at Rails needs attention and lot of fixes, since they eat memory like a hungry baby... and is not directly fault of Mongrel. Could be Ruby, rubygems, some plugin you''re using, even Rails :-P If you cannot revert back to the version of rubygems you was using to test the exact same environment, there is nothing more we can do except: thank god you got that solved! :-P Maybe you can see bleakhouse [2] and give it a whirl? [1] http://brainspl.at/articles/2008/04/25/hey-rails-nice-rack [2] http://blog.evanweaver.com/articles/2008/04/06/bleakhouse-4/ -- Luis Lavena Multimedia systems - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams
On Mon, Apr 28, 2008 at 2:23 PM, Evan Weaver <evan at cloudbur.st> wrote:> Maybe the upgrade installed fastthread?Could have. Prolly wouldn''t have done much since I''m running patch 111.> Most likely though it''s related to the Rails app itself, not Mongrel, > and isn''t immediately reproducible. Cache freshness could have a large > effect on which codepaths get traversed.It happened even with a ''blank, vanilla'' rails app. All I had to do was add an extra thread and run it in mongrel. rails 1.2.3 I believe the problem ''kicked off'' no matter what page I requested--meaning that basically rails had to load. I wonder if the problem is that I started a thread BEFORE rails loaded, and so some of that ''non thread safeness'' of Ruby came back to haunt me or something. It confused scopes or something. [1]> What did you add that Thread loop for? I don''t understand.Originally it was a ''helper thread'' that restarted my app if in production and any files were changed. Then I saw that leaks were happening, and replaced it with that one, to exaggerate the problem. and was successful :) I almost wish I could recreate it so I could kill these leaking bugs once and for all. I was this close from diving into eval.c and tearing into ruby''s gc until I squashed it. So much for recreation I guess. As a side-note, from [1] we see that Ruby, at least the MRI of that post, had some sockets that would be cross-threaded. I still can''t figure out why this doesn''t occur with mongrel. Hmm. -R [1] http://64.233.167.104/search?q=cache:Ilkzvy47LgcJ:permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245+zed+shaw+rails+thread+safety&hl=en&gl=us&ct=clnk&cd=1