Issue #15667 has been updated by sam.saffron (Sam Saffron).

File crash.png added

@tessi 

My tests were with 3.6.0, I will do a side by side now that I have all the infrastructure of 5 vs 3.6 and even tcmalloc. 

Nice to see that gem! Looking at my graphs I think best bang would just be to spin a thread that does trimming every 10-30 minutes or something, especially if you can release the GVL prior to calling it (provided this thing is thread safe, which @carlos should know)
 

----------------------------------------
Feature #15667: Introduce malloc_trim(0) in full gc cycles
https://bugs.ruby-lang.org/issues/15667#change-77394

* Author: sam.saffron (Sam Saffron)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Per Hongli's excellent article it looks like malloc_trim can help tremendously with memory bloat issues. 


https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html#a-magic-trick-trimming


I would like to get this patch tested side-by-side at Discourse, GitHub and Shopify. If it looks good I think this is both a great candidate for 2.7 and and 2.4,2.5,2.6 backports. 


Will coordinate with Shopify and GitHub to see if we can get numbers posted here, I will run tests on a live Discourse instance over the next week and report numbers here. 

Koichi, what are your thoughts, to me this looks like an incredibly safe patch, the amount of work added to major GCs is tiny compared to the potential benefit, walking all pages is a very cheap operation.



---Files--------------------------------
ruby_gc_malloc_trim.patch (1011 Bytes)
Screenshot_2019-03-28 Grafana - Compare Discourse Perf.png (530 KB)
crash.png (85.9 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>