There is some decent amount of information in that article= , it's a great food for thought, for me I actually decided to use jmall= oc for a production service and the problem were specifically related to si= dekiq workers not releasing memory effectively when jobs are consumed.=C2= =A0

Anyone have an idea if setting=C2=A0M_TRIM_THRESHOLD for a value like 40 or 80 bytes would actually help in this case, as I= believe it should automatically return memory to the system. I will try us= ing its environment variable and test if there are any improvement by just = using that variable.

All in all, great job everyon= e.

On Mon, Apr 1, 2019 at 6:05 AM <sam.saffron@gmail.com> wrote:

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, espec= ially if you can release the GVL prior to calling it (provided this thing i= s thread safe, which @carlos should know)

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

* Author: sam.saffron (Sam Saffron)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Per Hongli's excellent article it looks like malloc_trim can help treme= ndously 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 a= nd 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 pa= tch, the amount of work added to major GCs is tiny compared to the potentia= l 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=3Dunsubscribe= >
<http://lists.ruby-lang.org/cgi-bin/m= ailman/options/ruby-core>