https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112017-01-20T03:33:55ZRuby Issue Tracking SystemRuby master - Feature #12967: Add a default for RUBY_GC_HEAP_GROWTH_MAX_SLOTS out-of-the-boxhttps://bugs.ruby-lang.org/issues/12967?journal_id=625982017-01-20T03:33:55Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>We looked at this issue at yesterday's developer meeting.</p>
<p>Ko1 said he was not sure if the proposed default value is decent. Also he said to me that there should be some kind of comprehensive approach to parameterize GC. It seems he thinks sporadic use of environment variables make things complicated.</p> Ruby master - Feature #12967: Add a default for RUBY_GC_HEAP_GROWTH_MAX_SLOTS out-of-the-boxhttps://bugs.ruby-lang.org/issues/12967?journal_id=626842017-01-26T10:25:01Zko1 (Koichi Sasada)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><blockquote>
<p>My suggestion is to ship with a far safer default of: RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000</p>
</blockquote>
<p>To define "safe" is difficult. Providing tuning parameter is enough for this purpose.</p> Ruby master - Feature #12967: Add a default for RUBY_GC_HEAP_GROWTH_MAX_SLOTS out-of-the-boxhttps://bugs.ruby-lang.org/issues/12967?journal_id=629092017-02-08T00:41:44Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-6 priority-4 priority-default closed" title="Feature: Add a default for RUBY_GC_HEAP_GROWTH_MAX_SLOTS out-of-the-box (Rejected)" href="https://bugs.ruby-lang.org/issues/12967">#12967</a> has been updated by Koichi Sasada.</p>
<p>Status changed from Open to Rejected</p>
<blockquote>
<p>My suggestion is to ship with a far safer default of: RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000</p>
</blockquote>
<p>To define "safe" is difficult. Providing tuning parameter is enough for this purpose.</p>
</blockquote>
<p>I think a problem is few people know tuning parameters (even if<br>
we documented in the ruby(1) manpage), and some tuning parameter<br>
behaviors may change with time.</p>
<p>So, we should try to find better defaults for the common case.</p>
<p>Maybe it's just me, but I have more problems with memory usage<br>
than speed with Ruby. I think Sam and most other Rails users<br>
will agree with me.</p>
<p>For tracking down high memory usage in apps, I prefer<br>
single-threaded servers since it's easier to track down what<br>
code was executing when big growths happen. But single-threaded<br>
is also not memory-efficient....</p>
<p>Unfortunately, tracking/controlling memory growth in a<br>
multi-threaded, shared heap processes is not easy, either;<br>
especially when they have to know how their malloc()<br>
implementation works, and what tuning there is, too.</p>
<p>In my experience, typical Ruby programmers would rather not be<br>
going through their entire code base to hunt memory growth<br>
locations, regardless of single or multi-thread. Instead, I see<br>
people either buy more memory, or abandon Ruby.</p>
<p>Anyways, I don't think RUBY_GC_HEAP_GROWTH_MAX_SLOTS=100000<br>
will hurt anyone.</p> Ruby master - Feature #12967: Add a default for RUBY_GC_HEAP_GROWTH_MAX_SLOTS out-of-the-boxhttps://bugs.ruby-lang.org/issues/12967?journal_id=705012018-02-20T15:13:34Znnc (Nemanja Chorlya)
<ul></ul><p>IMHO this should be reconsidered, as it provides a huge memory saving for a typical Rails app and it's so easy and unobtrusive, but almost no one is aware of it<br>
But if it was capped like this out of the box, a lot more people would benefit and have a better experience with Ruby, especially on memory constrained environments like Heroku. Just by tweaking RUBY_GC_HEAP_GROWTH_MAX_SLOTS we were able to use smaller dynos and save a lot of money on our Heroku bills.</p>