ruby - 使用 jemalloc 调试 sidekiq worker 内存泄漏

Question

因此，我的 Sidekiq worker 出现了内存泄漏。我有一个工作服务器，只有一个队列用于这个工作任务，一周内达到大约 10G RSS。

我尝试只用 1 个工作线程在本地重现它，瞧 - 我在一晚上从 200M 增加到 1G，每分钟处理 1 个任务。自然地，我想知道泄漏了什么，所以我还记录了 RSS、heap_live_slots 和 heap_free_slots。当我绘制结果时，我可以看到稳定的 RSS增长同时live and free slots随机波动，但在定义明确且恒定的边界内，而它们的总和保持不变。

此时我得出的结论是，泄漏可能不是发生在 Ruby 代码中，而是发生在某些 native 扩展中。所以我通过 RVM 重新安装带有 Jemalloc 支持的 ruby​​:rvm 重新安装 2.4.2 --with-jemalloc

然后我设置MALLOC_CONF:

导出
MALLOC_CONF='prof_leak:true,lg_prof_sample:0,prof_final:true,stats_print:true'

然后启动 Sidekiq。新启动的带有 1 个工作线程的 Sidekiq 值(value)大约 200M RSS，但是当我按下 Ctrl+C 并查看 jemalloc 的统计输出时，我看到了一些完全不同的东西:

Arenas: 32
Quantum size: 16
Page size: 4096
Maximum thread-cached size class: 32768
Allocated: 34056, active: 61440, metadata: 2949272, resident: 2981888, mapped: 6352896, retained: 2035712

什么？ 6M映射？这不可能是真的。所以我启动 irb 并执行以下操作:

2.4.2 :001 > arr = []
 => [] 
2.4.2 :002 > loop do
2.4.2 :003 >   arr << 'a'*10000000
2.4.2 :004?>   sleep 1
2.4.2 :005?> end

等到 irb 进程攀升到大约 1G RSS 后，我停止了进程...并看到完全相同的数字。也许可视化调用图会帮助我了解发生了什么？

jeprof --show_bytes --pdf `which ruby` jeprof.10536.0.f.heap > ruby.pdf

Using local file /home/mhi/.rvm/rubies/ruby-2.4.2/bin/ruby.
Using local file jeprof.10536.0.f.heap.
No nodes to print

所以显然有些地方出了问题，这就是我需要帮助解决的问题。

这是 jemalloc stat 的完整输出:https://pastebin.com/RiMLtqA6

UPD。

所以我已经更新了所有与 native 扩展相关的 gem，这里是输出bundle exec ruby​​ -e 'puts Gem.loaded_specs.values.select{ |i| !i.extensions.empty？ }.map{ |i| "#{i.name} #{i.version}"}':

io-console 0.4.6
nokogiri 1.8.1
bcrypt 3.1.11
debug_inspector 0.0.3
binding_of_caller 0.7.2
json 2.1.0
capybara-webkit 1.14.0
damerau-levenshtein 1.3.0
unf_ext 0.0.7.4
eventmachine 1.2.5
ffi 1.9.18
kgio 2.11.0
msgpack 1.1.0
mysql2 0.4.9
rainbow 2.2.2
raindrops 0.18.0
rbtrace 0.4.8
stackprof 0.2.10
therubyracer 0.12.3
unicode 0.4.4.4
unicorn 5.3.0

相同的结果:RSS , Memory slots

Answer 1

Ruby 2.4.2 has a known issue with jemalloc .

这个问题大约一个月前关闭了，但我不知道你使用的软件包是否打了补丁......实际上，我认为补丁还没有发布。很可能所有 jemalloc 统计数据都不相关。

此外，这似乎是一个 X-Y question (你问的是 jemalloc，而你可能想要内存“泄漏”的解决方案)。

在假设 native 代码中存在内存泄漏(尽管可能性很大)之前，我会考虑任务的作用域如何影响垃圾收集器，并尝试最小化作用域和任何长期变量。

例如，如果您的任务是一个Proc，它可能会绑定(bind)到全局范围，这意味着某些变量可能永远存在...

尝试将任务包含在一个函数中，并确保任务完成后没有引用任何变量。