Ruby / Rails garbage collection

2019-02-13 13:32发布

Since http is stateless, every request to an app creates a new object. How does Rails clean up the unused objects / how frequently?

2条回答
SAY GOODBYE
2楼-- · 2019-02-13 13:50

If you are interested in this you should check out the blog series about copy-on-write garbage collection by the Phusion team and their efforts to improve on the default ruby gc scheme in Ruby Enterprise Edition.

http://izumi.plan99.net/blog/index.php/2007/04/05/saving-memory-in-ruby-on-rails/

Other links in the series here:

http://www.rubyenterpriseedition.com/faq.html

查看更多
狗以群分
3楼-- · 2019-02-13 13:53

Simple answer: the Ruby runtime has a garbage collector. Depending on the runtime (JRuby/JVM generational GC, IronRuby/CLR generational GC, classic Ruby/mark-sweep GC) different algorithms are used. But the basics are pretty simple:

  • Upon an allocation request if there is "insufficient free memory" available - how much is insufficient is one of the ingredients of the GC algorithm - then a GC will commence
  • The GC starts by scanning roots, which are global variables and stack locations (parameters and local variables), to discover which objects are still alive; it marks each object it finds
  • Then, the GC process looks at links (references) inside these objects, and recurses into those objects that haven't already been marked
  • The GC can then start moving / copying all marked objects so that they are compacted in memory
  • The "free pointer", from whence new allocations occur, is reset to the end of this compacted chunk of memory
  • If there is still "insufficient free memory", then more is allocated from the operating system
  • All old objects that weren't marked during the scanning process are garbage and are implicitly discarded through the copying process and resetting of the free pointer.

The frequency of collections depends on the tuning of the GC, which may be affected by the operating system, the amount of physical memory, operating system memory pressure, user-controlled tweaks, underlying platform version revisions, dynamically optimized parameters, etc. Much of it comes down to deciding where the bar lies in that "insufficient free memory" test, though things get more complicated with generational collectors.

查看更多
登录 后发表回答