Kirk Haines wrote: > On 10/3/07, Chris Taggart <[EMAIL PROTECTED]> wrote: >> -- on startup (before any requests have been made), the testbed (64-bit) >> server uses 87% more memory than the staging one (78MB vs 42MB) > > This appears to be in the reasonable ballpark of what to expect, based > on my testing with a bunch of different frameworks.
So just to clarify, the 80%+ is not uncommon for 64-bit vs 32-bit. Any benefits (as far as mongrel is concerned) to being on 64-bt, or (if it's possible) is it worth running the app servers on 32-bit kernels? > >> -- on the first request, both increase memory usage by 17%, and then >> both gradually climb by varying percentages, though the testbed's mem >> usage is always 80-95% more than the 32-bit staging server. > > The initial bump is probably a factor of Rails and of your > application's object initializations. > That's what I figured > An ongoing memory increase, though, is caused either by your > application intentionally caching things in RAM, or by something > leaking. RAM usage should stay pretty stable. > The caching is all done using fragment caching (on disk -- haven't yet investigated memcached). >> -- memory usage increases inconsistently, sometimes staying the same >> when the requests are repeated, sometimes increasing. I'm wondering if >> this could be a memory leak to do with caching (which might explain why >> it wasn't showing up when I was httperf'ing the staging server). > > It could be. It could be that something your app is using is leaking, > or that you are hitting a memory leak in Ruby. As of 1.8.6, the > Array#shift bug is fixed, but there are probably others. I > demonstrated a leak a few months ago in one of the get*by* methods. > gethostbyname, IIRC, and I have no doubt that if one took the time to > look into this intently, other leaky libs could be found. Do you use > rmagick? Historically, people have had a lot of memory leak issues > with it. > I'd read about the Array#shift bug and had removed it everywhere but one place (must do that), but doing a search of the app see that it's used elsewhere, including a number of plugins and rails itself. I ditched rmagick some time ago due to concerns about it and no use ImageScience. >> There's obviously more work to be done here, but all comments and >> suggestions are welcome. This is new territory for me, so I may be >> missing something completely obvious. > > Tracking down memory leaks in Ruby is a labor intensive process. Good > luck. > Any suggestions for best practice/howtos/etc? > > Kirk Haines -- Posted via http://www.ruby-forum.com/. _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users