Closed jrafanie closed 4 years ago
This issue has been automatically marked as stale because it has not been updated for at least 6 months.
If you can still reproduce this issue on the current release or on master
, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions!
@jrafanie and while I am bothering you, do you still see this as a worthwhile endeavor to pursue?
Good question @NickLaMuro. jemalloc is supposed to be so much better and maybe I was benchmarking it incorrectly but it didn't seem to be help us.
https://brandonhilkert.com/blog/reducing-sidekiq-memory-usage-with-jemalloc/
https://www.mikeperham.com/2018/04/25/taming-rails-memory-bloat/
@jrafanie does your response mean you want this issue to remain open. If yes, can you remove the stale label.
If there's no update by next week, I'll be closing this issue.
Yes, I think this is worthwhile researching since my testing wasn't very scientific and there could be some memory savings using jemalloc on appliances. Removed the stale label.
Thanks @jrafanie and also for removing the stale label.
@jrafanie I thought you saw a 10% reduction. That alone seems worthwhile.
Is there any chance you're already using a version of Ruby with jemalloc enabled?
@djberg96 I wasn't seeing the 50% improvement or even 20% that other places on the web were reporting. I'm not saying that it's not an improvement but maybe my testing methodology was flawed.
Are you seeing improvements when you're using jemalloc?
I was seeing around a 10% improvement for most things, but the UI seemed to get 30-40%. I think @himdel was seeing around the same thing.
Anyway, I think it would be worth making the default if possible, though I don't know how we would deploy jemalloc to production exactly.
So, it really depends on what we're measuring.
Running rails s
, and measuring using what htop
says, after having logged in and loaded the dashboards:
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 bin/rails s
virt 1224M res 699M shr 19220
$ bin/rails s
virt 1688M res 514M shr 18416
Measuring using smem -krs pss -P puma\ \\d
:
with libjemalloc2 5.1.0-2
:
after booting
9153 himdel puma 3.7.1 (tcp://localhost 0 275.2M 276.0M 284.0M
on login screen
9153 himdel puma 3.7.1 (tcp://localhost 0 690.1M 690.9M 699.3M
dashboard loaded
9153 himdel puma 3.7.1 (tcp://localhost 0 797.3M 798.4M 808.6M
with regular malloc: after booting 10085 himdel puma 3.7.1 (tcp://localhost 0 165.2M 166.0M 173.3M on login screen 10085 himdel puma 3.7.1 (tcp://localhost 0 418.9M 419.6M 427.0M dashboard loaded 10085 himdel puma 3.7.1 (tcp://localhost 0 527.4M 528.4M 538.5M
All of that is ruby 2.4.3p205.
@himdel wow, jemalloc looks really bad
I wonder if some of that difference could be LD_PRELOAD vs building ruby with jemalloc, but, apart from virtual, the numbers do seem consistently higher, yeah.
(Or, there's also libjemalloc1 3.6.0-11 in debian, I haven't tried that one.)
Yeah, LD_PRELOAD could be at play here. I haven't reviewed the versions of jemalloc to know if one version is better than others.
If you're using rbenv, you can do RUBY_CONFIGURE_OPTS="--with-jemalloc" rbenv install 2.4.3
(or whichever version you use) to see if there's any benefit vs using LD_PRELOAD.
You can double check it with ruby -r rbconfig -e "puts RbConfig::CONFIG['LIBS']"
and you should see -ljemalloc
.
My own experiments showed roughly the same thing as @himdel whether Ruby was built with jemalloc or I used LD_PRELOAD.
@djberg96 beat me to it :)
Tried 2.4.4 built with jemalloc, and..
PID User Command Swap USS PSS RSS
18680 himdel puma 3.7.1 (tcp://localhost 0 170.4M 171.1M 177.2M
18680 himdel puma 3.7.1 (tcp://localhost 0 370.9M 371.5M 377.7M
18680 himdel puma 3.7.1 (tcp://localhost 0 490.0M 490.8M 498.6M
So.. I have no idea now :D
Though, at least subjectively, it seems I'm getting a bit more of those
^C
[----] I, [2019-02-01T15:24:24.929746 #18680:3ffa7e2d086c] INFO -- : Completed in 320417ms (ActiveRecord: 45.8ms)
[----] I, [2019-02-01T15:24:24.931011 #18680:3ffa7e2d05c4] INFO -- : Completed in 321260ms (ActiveRecord: 204.4ms)
hangs with the jemalloc version.
(But, hard to tell, it's not like they're not happening every day anyway :), just something we should test if we ever decide to build those)
This issue has been automatically marked as stale because it has not been updated for at least 6 months.
If you can still reproduce this issue on the current release or on master
, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions!
@miq-bot remove_label stale
@miq-bot add_label pinned
updating the issue with some attempts with rhel8/centos8:
jemalloc 5.2.1 is available with the OS update so I'm going to try it again.
Had to hack a powertools repo installation only for super insecure dev testing on RHEL8:
[root@localhost ~]# cat /etc/yum.repos.d/CentOS-PowerTools.repo
[PowerTools]
name=CentOS $releasever - PowerTools
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=PowerTools&infra=$infra
#baseurl=http://mirror.centos.org/$contentdir/$releasever/PowerTools/$basearch/os/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
This should work on centos8:
dnf config-manager --enable PowerTools
yum config-manager --set-enabled PowerTools
You can then install libyaml-devel
yum install libyaml-devel
You can then build/install ruby using ruby-install:
ruby-install --system ruby 2.5.7 -- --disable-install-doc --enable-shared --with-jemalloc
[root@localhost ~]# ruby -r rbconfig -e "puts RbConfig::CONFIG['LIBS']"
-lpthread -ljemalloc -ldl -lcrypt -lm
I tried using jemalloc again on mac but will need to really test with it over longer periods on appliances and containers to really see the performance improvements:
ruby-install 3.1 -- --with-openssl-dir=$(brew --prefix openssl@3) --with-jemalloc CPPFLAGS="-I$HOMEBREW_PREFIX/opt/jemalloc/include" LDFLAGS="-L$HOMEBREW_PREFIX/opt/jemalloc/lib"
At this point I'd be looking at 3.2 or 3.3 with yjit + jemalloc.
Hey @djberg96 !! :wave:
tl;dr Seems to save around 10% PSS
In
/etc/default/evm
, change:export PATH=$PATH:/opt/rubies/ruby-2.3.1/bin
To:export PATH=$PATH:/opt/rubies/ruby-2.3.2/bin
Very rough memory comparison for some of the workers.
Before, using malloc
After, using jemalloc
https://bugs.ruby-lang.org/issues/9113 2.2.0 was first release with this added option to configure with jemalloc: https://www.ruby-lang.org/en/news/2014/12/25/ruby-2-2-0-released/