4 ms·

Phusion Passenger author here. The article mentions that Unicorn's out-of-band garbage collection is problematic because the way it works - running the GC afte

Phusion Passenger author here. The article mentions that Unicorn's out-of-band garbage collection is problematic because the way it works - running the GC after every request, and requiring turning off the normal GC - is overkill. But there the community is working on a better solution. In particular, Aman Gupta described this very same problem and created a gem which improves out-of-band garbage collector, by only running it when it is actually necessary, and by not requiring one to turn off the normal GC. Phusion Passenger (even the open source version) already integrates with this improved out-of-band garbage collector through a configuration option. This all is described here: http://blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/ http://blog.phusion.nl/2014/01/31/phusion-passenger-now-supp... Just one caveat: it's still a work in progress. There's currently 1 known bug open that needs reviewing. Besides the GC stuff, Phusion Passenger also has a very nice feature called passenger_max_requests. It allows you to automatically restart a process after it has processed the given number of requests, thereby lowering its peak memory usage. As far as I know, Unicorn and Puma don't support this (at least not out of the box; whether there are third party tools for this, I don't know). And yes, this feature is in open source.

boundlessdreamz 13y ago
What's the known bug?
- benesch 13y ago
  The project appears to be called gctools: https://github.com/tmm1/gctools https://github.com/tmm1/gctools And the known bug is probably "Allow dry-running the OOBGC": https://github.com/tmm1/gctools/pull/5 https://github.com/tmm1/gctools/pull/5 Without knowing anything about the project, it seems like the bug is particular to Passenger's use case.
  - sams99 13y ago
    The bug, is not a "bug" its a feature missing to allow running with passenger. It works fine with unicorn.
- FooBarWidget 13y ago
  https://github.com/FooBarWidget/gctools/pull/1 https://github.com/FooBarWidget/gctools/pull/1
billrobertson42 13y ago
> running the GC after every request, and requiring turning off the normal GC - is overkill. Sort of reminiscent of Erlang's per-process GC. Although, given what I've seen of Ruby's internals, I'm sure the similarities stop at the very highest conceptual levels.
astrodust 13y ago
Based on what I've seen in NodeJS, isn't it about time that Ruby has some kind of temporary "Buffer" class that represents data in a way intrinsically different from String? This would allow explicit clearing of the data in a way that would break how String works, but in the context of Buffer it would be allowed. If the Ruby GC isn't cutting it for you, maybe old-school memory management is the way to go, right?
- phillmv 13y ago
  From the article, the issue is that the Ruby GC is triggered on total number of objects, and not total amount of used memory. The article claims this got worse with the new generational GC algorithm, which sought to minimize the amount of work the GC has to do during the collection pause. By marking long lived objects as probably OK, you end up with fewer objects to free per GC cycle. The problem then, is if you allocate some massive strings, and they get marked as "old" then they might never get collected by the GC. It's not clear to me if the article author sees it this way, but apparently there is some kind of bugs where some class of objects get marked "old" by accident, and it sounds like it's exacerbated by existing interpreter architecture. Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking. Anyhow, so, my understanding of your question is no, it would not help outside of really specific optimizations? It depends on what this Buffer class would do. Would they let you mark them as being young? Or avoid extra malloc calls because you have special information on the size of your strings? Kinda depends on how the generational algorithm was implemented? At this stage my knowledge grows thin.
  - gary4gar 13y ago
    Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking. This is wrong. Ruby Developers welcome contribution in any form. Also, they have various resource to get started: Official Contributing Guide: http://ruby-doc.org/core-2.1.1/doc/contributing_rdoc.html Ruby Hacking Guide: http://ruby-hacking-guide.github.io/ Book on ruby internals: http://www.amazon.com/Ruby-Under-Microscope-Illustrated-Internals/dp/1593275277 RubySpecs: http://rubyspec.org/ Further, incase you are stuck. you can post on the mailing-lists. someone will surely help you get started.

boundlessdreamz 13y ago

What's the known bug?

benesch 13y ago
The project appears to be called gctools: https://github.com/tmm1/gctools https://github.com/tmm1/gctools And the known bug is probably "Allow dry-running the OOBGC": https://github.com/tmm1/gctools/pull/5 https://github.com/tmm1/gctools/pull/5 Without knowing anything about the project, it seems like the bug is particular to Passenger's use case.
- sams99 13y ago
  The bug, is not a "bug" its a feature missing to allow running with passenger. It works fine with unicorn.
FooBarWidget 13y ago
https://github.com/FooBarWidget/gctools/pull/1 https://github.com/FooBarWidget/gctools/pull/1

billrobertson42 13y ago

> running the GC after every request, and requiring turning off the normal GC - is overkill. Sort of reminiscent of Erlang's per-process GC. Although, given what I've seen of Ruby's internals, I'm sure the similarities stop at the very highest conceptual levels.

astrodust 13y ago

Based on what I've seen in NodeJS, isn't it about time that Ruby has some kind of temporary "Buffer" class that represents data in a way intrinsically different from String? This would allow explicit clearing of the data in a way that would break how String works, but in the context of Buffer it would be allowed. If the Ruby GC isn't cutting it for you, maybe old-school memory management is the way to go, right?

phillmv 13y ago
From the article, the issue is that the Ruby GC is triggered on total number of objects, and not total amount of used memory. The article claims this got worse with the new generational GC algorithm, which sought to minimize the amount of work the GC has to do during the collection pause. By marking long lived objects as probably OK, you end up with fewer objects to free per GC cycle. The problem then, is if you allocate some massive strings, and they get marked as "old" then they might never get collected by the GC. It's not clear to me if the article author sees it this way, but apparently there is some kind of bugs where some class of objects get marked "old" by accident, and it sounds like it's exacerbated by existing interpreter architecture. Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking. Anyhow, so, my understanding of your question is no, it would not help outside of really specific optimizations? It depends on what this Buffer class would do. Would they let you mark them as being young? Or avoid extra malloc calls because you have special information on the size of your strings? Kinda depends on how the generational algorithm was implemented? At this stage my knowledge grows thin.
- gary4gar 13y ago
  Work on the Ruby interpreter is weirdly silo'ed off and mostly done by Japanese developers, so there's a significant barrier to entry for any enterprising C developer to roll her sleeves up and get hacking. This is wrong. Ruby Developers welcome contribution in any form. Also, they have various resource to get started: Official Contributing Guide: http://ruby-doc.org/core-2.1.1/doc/contributing_rdoc.html Ruby Hacking Guide: http://ruby-hacking-guide.github.io/ Book on ruby internals: http://www.amazon.com/Ruby-Under-Microscope-Illustrated-Internals/dp/1593275277 RubySpecs: http://rubyspec.org/ Further, incase you are stuck. you can post on the mailing-lists. someone will surely help you get started.