在定位内存泄漏时,我发现 ruby-prof 不是很有用,因为您需要一个修补过的 Ruby 解释器。在 Ruby 2.1 中跟踪对象分配变得更加容易。也许这是自己探索的最佳选择。
我推荐 Ruby 核心开发者之一 tmml 的博客文章Ruby 2.1: objspace.so。基本上,您可以在调试应用程序时获取大量信息:
ObjectSpace.each_object{ |o| ... }
ObjectSpace.count_objects #=> {:TOTAL=>55298, :FREE=>10289, :T_OBJECT=>3371, ...}
require 'objspace'
ObjectSpace.memsize_of(o) #=> 0 /* additional bytes allocated by object */
ObjectSpace.count_tdata_objects #=> {Encoding=>100, Time=>87, RubyVM::Env=>17, ...}
ObjectSpace.count_nodes #=> {:NODE_SCOPE=>2, :NODE_BLOCK=>688, :NODE_IF=>9, ...}
ObjectSpace.reachable_objects_from(o) #=> [referenced, objects, ...]
ObjectSpace.reachable_objects_from_root #=> {"symbols"=>..., "global_tbl"=>...} /* in 2.1 */
使用 Ruby 2.1,您甚至可以开始跟踪新对象的分配并收集有关每个新对象的元数据:
require 'objspace'
ObjectSpace.trace_object_allocations_start
class MyApp
def perform
"foobar"
end
end
o = MyApp.new.perform
ObjectSpace.allocation_sourcefile(o) #=> "example.rb"
ObjectSpace.allocation_sourceline(o) #=> 6
ObjectSpace.allocation_generation(o) #=> 1
ObjectSpace.allocation_class_path(o) #=> "MyApp"
ObjectSpace.allocation_method_id(o) #=> :perform
使用pry和pry-byebug并开始探索您认为可能会增长的内存堆,分别尝试代码中的不同段。在 Ruby 2.1 之前,我总是依赖ObjectSpace.count_objects
并计算结果的差异,以查看一种对象类型是否特别增长。
当不断增长的对象数量在迭代过程中被重新测试到更小的数量时,垃圾收集可以正常工作,而不是继续增长。无论如何,垃圾收集器应该一直运行,您可以通过查看垃圾收集器统计信息来让自己放心。
根据我的经验,这是字符串或符号 ( T_STRING
)。ruby 2.2.0 之前的符号不会被垃圾收集,因此请确保您的 CSV 或其部分不会在途中转换为符号。
如果您觉得不舒服,请尝试使用 JRuby 在 JVM 上运行您的代码。至少像 VisualVM 这样的工具可以更好地支持内存分析。