在 Ruby 中查找内存泄漏的原因

Question

我在我的 Rails 代码中发现了内存泄漏 - 也就是说，我发现了 what 代码泄漏，但没有发现 为什么 它泄漏。我已将其简化为不需要 Rails 的测试用例：

require 'csspool'
require 'ruby-mass'

def report
    puts 'Memory ' + `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`.strip.split.map(&:to_i)[1].to_s + 'KB'
    Mass.print
end

report

# note I do not store the return value here
CSSPool::CSS::Document.parse(File.new('/home/jason/big.css'))

ObjectSpace.garbage_collect
sleep 1

report

ruby-mass 据说可以让我看到内存中的所有对象。 CSSPool 是一个基于 racc 的 CSS 解析器。 /home/jason/big.css 是a 1.5MB CSS file。

这个输出：

Memory 9264KB

==================================================
 Objects within [] namespace
==================================================
  String: 7261
  RubyVM::InstructionSequence: 1151
  Array: 562
  Class: 313
  Regexp: 181
  Proc: 111
  Encoding: 99
  Gem::StubSpecification: 66
  Gem::StubSpecification::StubLine: 60
  Gem::Version: 60
  Module: 31
  Hash: 29
  Gem::Requirement: 25
  RubyVM::Env: 11
  Gem::Specification: 8
  Float: 7
  Gem::Dependency: 7
  Range: 4
  Bignum: 3
  IO: 3
  Mutex: 3
  Time: 3
  Object: 2
  ARGF.class: 1
  Binding: 1
  Complex: 1
  Data: 1
  Gem::PathSupport: 1
  IOError: 1
  MatchData: 1
  Monitor: 1
  NoMemoryError: 1
  Process::Status: 1
  Random: 1
  RubyVM: 1
  SystemStackError: 1
  Thread: 1
  ThreadGroup: 1
  fatal: 1
==================================================

Memory 258860KB

==================================================
 Objects within [] namespace
==================================================
  String: 7456
  RubyVM::InstructionSequence: 1151
  Array: 564
  Class: 313
  Regexp: 181
  Proc: 113
  Encoding: 99
  Gem::StubSpecification: 66
  Gem::StubSpecification::StubLine: 60
  Gem::Version: 60
  Module: 31
  Hash: 30
  Gem::Requirement: 25
  RubyVM::Env: 13
  Gem::Specification: 8
  Float: 7
  Gem::Dependency: 7
  Range: 4
  Bignum: 3
  IO: 3
  Mutex: 3
  Time: 3
  Object: 2
  ARGF.class: 1
  Binding: 1
  Complex: 1
  Data: 1
  Gem::PathSupport: 1
  IOError: 1
  MatchData: 1
  Monitor: 1
  NoMemoryError: 1
  Process::Status: 1
  Random: 1
  RubyVM: 1
  SystemStackError: 1
  Thread: 1
  ThreadGroup: 1
  fatal: 1
==================================================

您可以看到内存在方式上升。一些计数器上升，但不存在特定于 CSSPool 的对象。我使用 ruby​​-mass 的“索引”方法来检查具有如下引用的对象：

Mass.index.each do |k,v|
    v.each do |id|
        refs = Mass.references(Mass[id])
        puts refs if !refs.empty?
    end
end

但同样，这并没有给我任何与 CSSPool 相关的信息，只是 gem 信息等。

我也试过输出“GC.stat”...

puts GC.stat
CSSPool::CSS::Document.parse(File.new('/home/jason/big.css'))
ObjectSpace.garbage_collect
sleep 1
puts GC.stat

结果：

{:count=>4, :heap_used=>126, :heap_length=>138, :heap_increment=>12, :heap_live_num=>50924, :heap_free_num=>24595, :heap_final_num=>0, :total_allocated_object=>86030, :total_freed_object=>35106}
{:count=>16, :heap_used=>6039, :heap_length=>12933, :heap_increment=>3841, :heap_live_num=>13369, :heap_free_num=>2443302, :heap_final_num=>0, :total_allocated_object=>3771675, :total_freed_object=>3758306}

据我了解，如果一个对象没有被引用并且发生垃圾回收，那么应该从内存中清除该对象。但这似乎不是这里发生的事情。

我还阅读了有关 C 级内存泄漏的信息，并且由于 CSSPool 使用使用 C 代码的 Racc，我认为这是一种可能性。我已经通过 Valgrind 运行了我的代码：

valgrind --partial-loads-ok=yes --undef-value-errors=no --leak-check=full --fullpath-after= ruby leak.rb 2> valgrind.txt

结果为@​​987654325@。我不确定这是否证实了 C 级泄漏，因为我还读到 Ruby 使用 Valgrind 不理解的内存进行操作。

使用的版本：

• Ruby 2.0.0-p247（这是我的 Rails 应用运行的）
• Ruby 1.9.3-p392-ref（用于使用 ruby​​-mass 进行测试）
• 红宝石质量 0.1.3
• CSSPool 4.0.0 来自here
• CentOS 6.4 和 Ubuntu 13.10

Answer 1

您似乎正在这里进入失落的世界。我认为问题也不在于racc 中的 c 绑定。

Ruby 内存管理既优雅又麻烦。它将对象（名为RVALUEs）存储在所谓的堆中，大小约为16KB。在底层，RVALUE 是一个 c-struct，包含不同标准 ruby​​ 对象表示的union。

因此，堆存储 RVALUE 对象，其大小不超过 40 字节。对于String、Array、Hash 等对象，这意味着小对象可以放入堆中，但一旦达到阈值，就会分配 Ruby 堆之外的额外内存。

这个额外的内存是灵活的；一旦对象被 GC 处理，is 就会被释放。这就是为什么你的测试用例 big_string 显示内存上下行为：

def report
  puts 'Memory ' + `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`
          .strip.split.map(&:to_i)[1].to_s + 'KB'
end
report
big_var = " " * 10000000
report
big_var = nil 
report
ObjectSpace.garbage_collect
sleep 1
report
# ⇒ Memory 11788KB
# ⇒ Memory 65188KB
# ⇒ Memory 65188KB
# ⇒ Memory 11788KB

但堆（请参阅GC[:heap_length]）本身不会释放回到操作系统，一旦获得。看，我将对你的测试用例做一个简单的改动：

- big_var = " " * 10000000
+ big_var = 1_000_000.times.map(&:to_s)

然后，瞧：

# ⇒ Memory 11788KB
# ⇒ Memory 65188KB
# ⇒ Memory 65188KB
# ⇒ Memory 57448KB

内存不再释放回操作系统，因为我引入的数组的每个元素适合RVALUE 大小并且存储在 ruby​​ 堆中。

如果您在 GC 运行后检查 GC.stat 的输出，您会发现 GC[:heap_used] 的值按预期减少。 Ruby 现在有很多空堆，准备好了。

总结：我不认为，c 代码泄漏。我认为问题在于css 中巨大图像的 base64 表示形式。我不知道解析器内部发生了什么，但看起来巨大的字符串迫使 ruby​​ 堆计数增加。

希望对您有所帮助。

Answer 2

好的，我找到了答案。我将留下我的另一个答案，因为该信息很难收集，它是相关的，并且可以帮助其他人搜索相关问题。

然而，您的问题似乎是由于 Ruby 实际上不在获得内存后将内存释放回操作系统。

内存分配

虽然 Ruby 程序员并不经常担心内存分配，但有时会出现以下问题：

为什么在我清除了对大对象的所有引用之后，我的 Ruby 进程仍然如此庞大？我/肯定/ GC 已经运行了几次并释放了我的大对象并且我没有泄漏内存。

C 程序员可能会问同样的问题：

我free()-ed了很多内存，为什么我的进程还是这么大？

从内核分配给用户空间的内存在大块中更便宜，因此用户空间通过自己做更多的工作来避免与内核的交互。

用户空间库/运行时实现了一个内存分配器（例如：libc 中的 malloc(3)），它占用大量内核内存 2 并将它们分成更小的块供用户空间应用程序使用。

因此，在用户空间需要向内核请求更多内存之前，可能会发生多次用户空间内存分配。因此，如果您从内核中获得了一大块内存并且只使用了其中的一小部分，那么该大块内存仍然处于分配状态。

将内存释放回内核也是有代价的。用户空间内存分配器可能会（私下）保留该内存，希望它可以在同一进程中重用，而不是将其交还给内核以供其他进程使用。 (Ruby Best Practices)

因此，您的对象很可能已被垃圾收集并释放回 Ruby 的可用内存，但由于 Ruby 从不将未使用的内存返还给操作系统，因此进程的 rss 值保持不变，即使在垃圾收集之后也是如此。这实际上是设计使然。根据Mike Perham：

...而且由于 MRI 从不归还未使用的内存，我们的守护程序在仅使用 100-200 MB 时很容易占用 300-400MB。

请务必注意，这本质上是设计使然。 Ruby 的历史主要是作为文本处理的命令行工具，因此它重视快速启动和较小的内存占用。它不是为长时间运行的守护进程/服务器进程而设计的。 Java 在其客户端和服务器 VM 中进行了类似的权衡。

Answer 3

根据@mudasobwa 的解释，我终于找到了原因。 CSSPool 中的代码正在检查非常长的数据 URI 以查找转义序列。它会使用匹配转义序列或单个字符的正则表达式在 URI 上调用 scan，map 将这些结果转义，然后将 join 重新转换为字符串。这有效地为 URI 中的每个字符分配了一个字符串。 I modified it 到 gsub 的转义序列，似乎有相同的结果（所有测试都通过）并且大大减少了使用的结束内存。

使用与最初发布的相同的测试用例（减去Mass.print 输出），这是更改前的结果：

Memory 12404KB
Memory 292516KB

这是更改后的结果：

Memory 12236KB
Memory 19584KB

Answer 4

这可能是由于 Ruby 1.9.3 及更高版本中的“延迟扫描”功能所致。

延迟清除基本上意味着，在垃圾回收期间，Ruby 仅“清除”足够的对象以为它需要创建的新对象创建空间。它这样做是因为，当 Ruby 垃圾收集器运行时，其他任何事情都没有。这就是所谓的“停止世界”垃圾收集。

本质上，懒惰的扫描减少了 Ruby 需要“停止世界”的时间。你可以阅读更多关于懒惰扫的内容here。

你的RUBY_GC_MALLOC_LIMIT 环境变量是什么样的？

这是Sam Saffron's blog 中关于惰性扫描和 RUBY_GC_MALLOC_LIMIT 的摘录：

Ruby 2.0 中的 GC 有两种不同的风格。我们有一个“完整”的 GC，它在我们分配超过 malloc_limit 之后运行，还有一个惰性扫描（部分 GC），如果我们堆中的空闲槽用完，就会运行。

惰性扫描比完整 GC 花费的时间更少，但只执行部分 GC。它的目标是更频繁地执行一次短 GC，从而提高整体吞吐量。世界停止了，但时间更短了。

malloc_limit 设置为开箱即用的 8MB，您可以通过将 RUBY_GC_MALLOC_LIMIT 设置得更高来提高它。

您的RUBY_GC_MALLOC_LIMIT 非常高吗？我的设置为 100000000 (100MB)。默认值约为 8MB，但对于 Rails 应用程序，他们建议它更高一些。如果你的值太高，它可能会阻止 Ruby 删除垃圾对象，因为它认为它有足够的增长空间。