[ruby-core:92087] Re: [Ruby trunk Feature#15667] Introduce malloc_trim(0) in full gc cycles

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

Anyone have an idea if setting M_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 using its environment
variable and test if there are any improvement by just using that variable.

All in all, great job everyone.

On Mon, Apr 1, 2019 at 6:05 AM <[e-mail]> 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,
> 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:[e-mail]?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>

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