Ruby 2.5 support
wjordan opened this issue · 7 comments
Tracking Ruby 2.5 support in this issue.
Running require 'gctools/oobgc/unicorn_middleware' in Ruby 2.5.0 generates the following error:
LoadError (/var/lib/gems/2.5.0/gems/gctools-0.2.4/lib/gctools/oobgc.so: undefined symbol: rb_autoload - /var/lib/gems/2.5.0/gems/gctools-0.2.4/lib/gctools/oobgc.so)
This might be fixed in the next published release of 2.5.x by f6631c30.
I don't recommend using this OOBGC with Ruby 2.5. The GC has changed significantly and the algorithm used in this gem is no longer relevant.
I don't recommend using this OOBGC with Ruby 2.5. The GC has changed significantly and the algorithm used in this gem is no longer relevant.
Are you sure? Do you have more details or references to profiling, benchmarking, or code-analysis that could help me confirm this?
@peteygao in #11 (comment) responded to your original comment that out-of-band GC still provides significantly different performance behavior compared to Ruby 2.2+'s incremental GC alone, making this gem still relevant in certain use-cases.
In my own monitoring of production metrics on a high-traffic Rails app running Ruby 2.2, I've seen out-of-band GC provide lower average request-latencies over the built-in RIncGC, which is why I still use this gem today and would like to maintain it through a Ruby 2.5 upgrade.
See for example https://githubengineering.com/removing-oobgc/
First, the linked post doesn't specify the specific OOBGC algorithm used. The difference between the naive 'OOBGC every X requests' algorithm and the more nuanced 'OOBGC only when finishing a sweep or when close to the allocation limit' algorithm is extremely significant.
Second, a single example where OOBGC turned out to be unhelpful doesn't contradict the claim that OOBGC for Ruby 2.2+ is still relevant in certain use cases. The benefits are workload-dependent.
Third, my own workload has consistently showed opposite results. I already mentioned that my own production metrics showed OOBGC provided lower average response times in Ruby 2.2. Since then, I've upgraded to Ruby 2.5 using the patch in #17. I just ran a direct side-by-side comparison, and continue to see OOBGC providing slightly (~10%) faster response times in production:
(blue = OOBGC disabled)
In our case, we noticed that by removing oobgc our response times at the 90th and 95th percentile got slower by ~10ms. I believe OobGC is still relevant.
Is there any downside of merge this change?
I would like to use it too, but use it directly from ruby gems and from the original repository would be better than point to the @wjordan fork directly.