From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 2EEEE1F424 for ; Fri, 27 Apr 2018 18:51:03 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 115A11209FC; Sat, 28 Apr 2018 03:51:00 +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 F14751209FB for ; Sat, 28 Apr 2018 03:50:57 +0900 (JST) Received: by filter0018p3las1.sendgrid.net with SMTP id filter0018p3las1-30165-5AE3710E-86 2018-04-27 18:50:54.961530917 +0000 UTC Received: from herokuapp.com (ec2-54-80-122-219.compute-1.amazonaws.com [54.80.122.219]) by ismtpd0009p1iad1.sendgrid.net (SG) with ESMTP id I1IIEU6wQga8H-h-m-VIPw Fri, 27 Apr 2018 18:50:54.822 +0000 (UTC) Date: Fri, 27 Apr 2018 18:50:55 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 62080 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14718 X-Redmine-Issue-Author: mperham X-Redmine-Sender: shevegen 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS67AE1ECLlO1ciyhrlcaocifcYwyMk+Fpbfnc I/Z+CnKfzZru4+7XFdvcndZqwQyvxBBYJtJPVFqmO6t7qGifygDRkRLEuEypKK5Xg1eP085tHnVuAd wWOcz8IMD3WTdjSX3yK48OlUoDP/U9y/8wdnebRTFAsrDV6p5N1WU8+ARg== X-ML-Name: ruby-core X-Mail-Count: 86734 Subject: [ruby-core:86734] [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 shevegen (Robert A. Heiler). I know way too little about the topic at hand, so I can not really comment on it, the usability, gains and so forth. I had a look at the discussion at #9113, just due to my curiosity alone. It seems as if matz has not yet commented on it; perhaps this issue has not been mentioned yet? If this is the case, then perhaps the issue here may be a good candidate for the next ruby-developer meeting. Matz has the "3x as fast" goal, so this may perhaps add another +0.5% or so? :D I guess what may be useful to know is if there is some summary or overview of trade offs for jemalloc by default, like pros and cons. I guess the pros have been mentioned already (less problems with memory) - are there cons that speak against the move? For example, by default, linux users using ruby, would they have to re-compile their ruby to benefit from this? Are there commandline switches? Questions like that. I am mostly asking so that information about it, also "trickles downwards" into more casual ruby hackers too. Ruby is used by people who don't know that much about the internals and may not know the differences between glibc and jemalloc. I myself know what glibc is but I never really heard of jemalloc before. It's great if they improved on something though. Are there really no disadvantages? (On a side note, glibc seems to be evolving quite slowly ... reminds me a bit of GCC versus LLVM but I may be wrong.) ---------------------------------------- Feature #14718: Use jemalloc by default? https://bugs.ruby-lang.org/issues/14718#change-71689 * 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. -- https://bugs.ruby-lang.org/