> My hunch is that rmagick is allocating large amounts of RAM ouside of > Ruby. It registers its objects with the interpreter, but the RAM > usage in rmagick itself doesn't count against GC_MALLOC_LIMIT because > Ruby didn't allocate it, so doesn't know about it.
It's allocating opaque objects on the Ruby heap but not using Ruby's built-in malloc? That seems pretty evil. Evan > > So, it uses huge amounts of RAM, but doesn't use huge numbers of > objects. Thus you never trigger a GC cycle by exceeding the > GC_MALLOC_LIMIT nor by running our of object slots in the heap. I'd > have to go look at the code to be sure, but the theory fits the > behavior that is described very well. > > I don't think this is a case for building GC.foo memory management > into Mongrel, though. As I think you are suggesting, just call > GC.start yourself in your code when necessary. In a typical Rails app > doing big things with rmagick, the extra time to do GC.start at the > end of the image manipulation, in the request handling, isn't going to > be noticable. > > > > But that's not really the overall point. My overall point is how to > > properly handle a rails app that uses a great deal of memory during each > > request. I'm pretty sure this happens in other rails applications that > > don't happen to use 'RMagick'. > > > > Personally, I'll simply say call the GC more often. Seriously. I mean it. > > It's not *that* slow, not at all. In fact, I call GC.start explicitly > inside > > of by ubygems.rb due to stuff I have observed before: > > I completely concur with this. If there are issues with huge memory > use (most likely caused by extensions making RAM allocations outside > of Ruby's accounting, so implicit GC isn't triggered), just call > GC.start in one's own code. > > > > Now, by my reckoning (and a few production apps seem to be showing > > emperically (purely emperical, sorry)) we should be calling on the GC > whilst > > loading up the apps. I mean come on, when are a really serious number of > > temporary objects being created. Actually, it's when rubygems loads, and > > that's the first thing that happens in, hmm, probably over 90% of ruby > > processes out there. > > Just as a tangent, I do this in Swiftiply. I make an explicit call to > GC.start after everything is loaded and all configs are parsed, just > to make sure execution is going into the main event loop with as much > junk cleaned out as possible. > > > > Or whatever. It doesn't really matter that much where you do this, or when, > > it just needs to happen every now and then. More importantly, add a > GC.start > > to the end of environment.rb, and you will have literally half the number > of > > objects in ObjectSpace. > > This makes sense to me. > > I could also see providing a 2nd Rails handler that had some GC > management stuff in it, along with some documentation on what it > actually does or does not do, so people can make an explicit choice to > use it, if they need it. I'm still completely against throwing code > into Mongrel itself for this sort of thing. I just prefer not to > throw more things into Mongrel than we really _need_ to, when there is > no strong argument for them being inside of Mongrel itself. GC.start > stuff is simple enough to put into one's own code at appropriate > locations, or to put into a customized Mongrel handler if one needs > it. > > Maybe this simply needs to be documented in the body of Mongrel > documentation? > > > Kirk Haines > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > -- Evan Weaver Cloudburst, LLC _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
