问题
I read quite a lot on Google that ruby does not release back memory to the OS and I understand the as well because allocating memory from OS is a costly fair.
Which has led me to ask this
If a developer want the Ruby to release the memory back to OS from ruby how do they do it.
- I guess the answer is manually triggering a GC in Ruby.
But is it advisable to do (run manual GC) on a production application.
I'm thinking of creating a separate thread(or Actor) in Celluloid to start a GC at every 2 hours time.
Can anyone suggest. Is the above solution advisable for production.
Note: I think I also know GC.start (means stop the whole world in Ruby)
Note: Ruby Version 2.2.2 MRI Centos 4G RAM with 4 core.
And here is the reason for the question http://pastebin.com/rYdYwxLJ
回答1:
I read quite a lot on Google that ruby does not release back memory to the OS and I understand the as well because allocating memory from OS is a costly fair.
That's simply not true. The Ruby Language doesn't say anything at all about releasing memory back to the OS. In fact, the Ruby Language doesn't say anything about memory, period.
There are a lot of different implementations of Ruby with a lot of different memory allocators and a lot of different garbage collectors. Some release memory back to the OS, some don't, some run on top of a managed runtime and don't even manage memory at all.
For example, JRuby running on J9 will release memory back to the OS. JRuby running on HotSpot with the G1 GC, ParallelScavenge GC, or ParallelOld GC will release memory back to the OS.
If a developer want the Ruby to release the memory back to OS from ruby how do they do it.
You don't. Either the implementation releases memory back to the OS, in which case you don't need to do anything, or it doesn't release memory back to the OS, in which you cannot do anything.
- I guess the answer is manually triggering a
GCin Ruby.
If the implementation doesn't release memory back to the OS, then it doesn't release memory back to the OS. Period.
If the implementation does release memory back to the OS, then it will do that whether you manually trigger a GC or not.
By the way: you cannot manually trigger a GC in Ruby. You can suggest a GC (using GC::start), but not trigger it.
But is it advisable to do (run manual GC) on a production application.
Pretty much never. The GC knows better than you do whether it makes sense to run now or at a later time.
Note: I think I also know GC.start (means stop the whole world in Ruby)
No, GC::start simply suggests to do a GC. It does not force a GC. Also, GC does not mean stop-the-world. E.g. when running JRuby on the J9 JVM with the Metronome GC or running JRuby on the Azul Zing JVM with the Pauseless GC will never stop-the-world.
Note: Ruby Version 2.2.2
That's not the interesting bit. The interesting question is which implementation you are using, which garbage collector, and which OS. (And of course the versions and configuration settings for all of those.)
回答2:
You likely misunderstood what you have read via Google links. The memory, that Ruby (here and after I mean MRI as default Ruby implementation) does not release back to OS (so-called Ruby Heaps,) is not released to OS. Period.
You have no ability to force Ruby to release Ruby Heaps back to OS (besides cold restart of the whole application.)
What might be released back to OS, is released by Ruby internally and it is a bad practice by all means to call GC manually, in 99% of cases that will slow down the application, in the rest 1% this will have no effect at all.
来源：https://stackoverflow.com/questions/38658067/is-it-good-practice-to-run-manual-gc-in-ruby