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. > -- 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. 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. > -- 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. > 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. Kirk Haines _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
