Ruby Ruby 用 jemalloc 有什么坑么？
看了几篇文章，jemalloc 对多线程的 ruby 应用内存占用有奇效（据说还有一点点的性能提升），遂拉了给生产环境加了两台机器，一台 Unicorn，一台 Sidekiq，用 2.3.7+jemalloc 编译。
线上跑了一天多，Sidekiq 的内存占用下降的非常可观，由最大 3G -> 700M，GC 时间略有下降，不错不错。Unicorn 的内存占用大概有一成的降幅，压的很稳，响应时间基本持平，CPU 目测个位数下降，毕竟 Unicorn 多进程，有改善已经是很满意了。
现在感觉可以把线上的 ruby 都切了。那么问题来了，jemalloc 还有什么坑呢？有没有使用体验分享？谢谢。
jasl
回复
兼容问题是指怎样的表现？编译不能？运行有内存泄露？还是什么的... 不过我们估计不会直接上 2.5，rails 升级之后，稳妥点还是先上 2.4.x
ksec
回复
Geeze now I don’t remember. I’ll kick it up again on Monday and see what happens. We were seeing some deadlocks at the same time because we were server side rendering react with execjs, so maybe jemalloc and V8 don’t get along. 是指这个？
还是说 ruby 官方那个冗长的讨论...
nouse
回复
改的只是内存管理的部分吧... 目前已经跑了三天，没有看到什么异常，不过线上我是全部重新 bundle 的，gem 也是全新编译。
就你说的这个我还在 CI 上尝试了原版 237 的 GEMS 直接替换 RUBY，不做重新 bundle，CI 也是全通过的。
https://www.mikeperham.com/2018/04/25/taming-rails-memory-bloat/ 这个人也是 Sidekiq 下降很多，如果只有 Sidekiq 有奇效，Ruby core team 不会认为是 Ruby 的问题。
nouse
回复
对多线程有奇效，因为我并没有用 Puma，所以不知道 Puma 的表现
但是 Unicorn 也有至少 15% 的内存占用下降，我觉得很不错
使用 slim 镜像的情况下，jemalloc 确实可以很大的改进内存占用情况
下图前半部分是 arwineap/docker-ruby-nokogiri-phantomjs 没有使用 jemalloc
后半部分是同一个镜像开启了 jemalloc
我发现 alpine 镜像的内存情况比 使用 jemalloc 的 slim 镜像要好很多
下图前半部分是 hoteltonight/ruby-jemalloc:2.5.1-stretch-slim
后半部分是 ruby:2.5.1-alpine
- docker
ruby:2.5.1-alpine用不了 jemalloc - docker
ruby:2.4.1-alpine用不了 jemalloc
测试方法 (参考楼上)：
- Dockerfile 中增加
RUN apk add --no-cache jemalloc - docker_compose.yml 中增加
environment:
LD_PRELOAD: '/usr/lib/libjemalloc.so.2'
https://github.com/docker-library/ruby/pull/198 在这里可以找到 alpine 不行的相关信息
ksec
回复
看起来是提了段代码，但是具体从哪个版本开始还不明朗
我目前在 Unicorn+Sidekiq 下运行了两周接近三周，没有遇到什么问题，中间还经历了从 Rails 4.2 -> 5.1，一切正常，准备完全切换到 jemalloc 了
