From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.1 required=3.0 tests=BAYES_00,FORGED_HOTMAIL_RCVD2, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id D53EE1F453 for ; Sat, 9 Feb 2019 04:42:12 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E3ADF121689; Sat, 9 Feb 2019 13:42:07 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 2607B121649 for ; Sat, 9 Feb 2019 13:42:05 +0900 (JST) Received: by filter0108p3las1.sendgrid.net with SMTP id filter0108p3las1-20546-5C5E5A1A-2C 2019-02-09 04:42:03.038757786 +0000 UTC m=+294333.478854330 Received: from herokuapp.com (ec2-100-27-20-2.compute-1.amazonaws.com [100.27.20.2]) by ismtpd0030p1mdw1.sendgrid.net (SG) with ESMTP id nhFKKpo7TnacPzovcpIghw for ; Sat, 09 Feb 2019 04:42:02.782 +0000 (UTC) Date: Sat, 09 Feb 2019 04:42:04 +0000 (UTC) From: dennisb55@hotmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66952 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14718 X-Redmine-Issue-Author: mperham X-Redmine-Sender: bluz71 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6uPzOJMioRsk4zfenn88E06JM8Y2+Vgo6MO+ za0EDCkSSK2uFlQIvNg2epc0jT8wv91d4+o4PbpY57GkAeNm++XPXhrCoZ6Y++S+bkkqzfK1s1rvR3 CcMTeGR5Fk1ylK5iW5qKj9rv3EuQzVTvMUCt9u8wFoxfi2jgffZnaG8ZwA== X-ML-Name: ruby-core X-Mail-Count: 91499 Subject: [ruby-core:91499] [Ruby trunk Feature#14718] Use jemalloc by default? X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14718 has been updated by bluz71 (Dennis B). Very interesting news indeed about Rust. Thanks for the update. Ruby 2.6 came and went, allocator remained unchanged though two nice enhancements were incorporated, transient-heap and disabled THP. Sam Saffron tweeted the other day about improved performance of 2.6 with Discourse. Anyway, I really hope the Red Hat / glibc crew are doing work to improve fragmentation behaviour (as noted above). Not changing allocator for Ruby was the correct choice. I suspect this issue can be closed, it is unlikely to ever happen. Until glibc improves I am still a proponent of [#14759](https://bugs.ruby-lang.org/issues/14759) *set M_ARENA_MAX for glibc malloc*. Eric, are you still wanting to do that? ---------------------------------------- Feature #14718: Use jemalloc by default? https://bugs.ruby-lang.org/issues/14718#change-76759 * Author: mperham (Mike Perham) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- I know Sam opened #9113 4 years ago to suggest this but I'm revisiting the topic to see if there's any movement here for Ruby 2.6 or 2.7. I supply a major piece of Ruby infrastructure (Sidekiq) and I keep hearing over and over how Ruby is terrible with memory, a huge memory hog with their Rails apps. My users switch to jemalloc and a miracle occurs: their memory usage drops massively. Some data points: https://twitter.com/brandonhilkert/status/987400365627801601 https://twitter.com/d_jones/status/989866391787335680 https://github.com/mperham/sidekiq/issues/3824#issuecomment-383072469 Redis moved to jemalloc many years ago and it solved all of their memory issues too. Their conclusion: the glibc allocator "sucks really really hard". http://oldblog.antirez.com/post/everything-about-redis-24.html This is a real pain point for the entire Rails community and would improve Ruby's reputation immensely if we can solve this problem. ---Files-------------------------------- glibc_arena_2.png (7.23 KB) jemalloc.png (21.1 KB) glibc-arena-2.log (60.3 KB) glibc.log (62.3 KB) jemalloc-3-5.log (58.5 KB) glibc.png (9.03 KB) -- https://bugs.ruby-lang.org/