ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: sam.saffron@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:92027] [Ruby trunk Feature#15667] Introduce malloc_trim(0) in full gc cycles
Date: Thu, 28 Mar 2019 01:52:17 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-77352.20190328015215.7e5c0e99ec1414cd@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15667.20190314203432@ruby-lang.org

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

File Screenshot_2019-03-28 Grafana - Compare Discourse Perf.png added

@mame / @carlos attached is a screenshot of side by side testing on live traffic patterns

containers run multiple ruby processes (a few unicorn workers and a sidekiq worker)

standard14 = Ruby 2.6.2 + jemalloc
standard14_a = Ruby 2.6.2 + glibc malloc
standard14_b = Ruby 2.6.2 + glibc malloc + patch

My conclusions from these graphs:

- Memory is clearly down with the patch
- 99th percentile performance is slightly impacted
- cpu is very slightly higher
- jemalloc still fairs better than glibc even after the patch


I think I would support a slightly amended patch that only does the trim once every say 10 minutes (maybe even in a background thread), happy to test that out as well. 

That said... selfishly for Discourse this does not matter that much we will still stick with jemalloc cause memory is better and performance is better under jemalloc. 

For the wider ruby community though a safer default is very appealing. 

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

* 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)


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

  parent reply	other threads:[~2019-03-28  1:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15667.20190314203432@ruby-lang.org>
2019-03-14 20:34 ` [ruby-core:91837] [Ruby trunk Feature#15667] Introduce malloc_trim(0) in full gc cycles sam.saffron
2019-03-17 23:15   ` [ruby-core:91858] " Eric Wong
2019-03-14 23:50 ` [ruby-core:91841] " sam.saffron
2019-03-20  1:40 ` [ruby-core:91889] " mame
2019-03-25  0:52 ` [ruby-core:91968] " sam.saffron
2019-03-28  1:52 ` sam.saffron [this message]
2019-03-29  4:30 ` [ruby-core:92046] " dennisb55
2019-03-31  1:52 ` [ruby-core:92060] " philipp
2019-04-01  4:05 ` [ruby-core:92070] " sam.saffron
2019-04-01  9:28   ` [ruby-core:92087] " Waheed Al-Barghouthi
2019-04-01  9:53     ` [ruby-core:92088] " Martin J. Dürst
2019-09-19  8:07 ` [ruby-core:94981] [Ruby master " dosadnizub

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-77352.20190328015215.7e5c0e99ec1414cd@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).