1.8.x的新修复解决了内存泄漏问题并改进了性能

作者 Werner Schuster 译者 张龙 发布于 2009年1月8日

领域

架构 & 设计,

语言 & 开发

主题

运行时 ,

Ruby on Rails ,

性能和可伸缩性 ,

Ruby

标签

Rails ,

垃圾回收

就性能而言，目前Ruby 1.9.1和JRuby领导着Ruby的实现。然而由于种种原因，转到这两个实现中的任何一个都不是那么容易的事情，因为Ruby 1.9.x在有些地方与1.8.7不兼容，同时JRuby仍旧缺乏一些使用本地扩展的Ruby库。由于这个原因，MRI 1.8.x还会继续存在一段时间，那么我们可能对其性能的改进产生兴趣。

目前Brent Roman在一定程度上改进了Ruby 1.8.x MRI的性能。他正不断尝试着修复Ruby中的内存泄漏问题。

基本的技术就是对Kurt Stephens所建议的一个问题的精化。它不仅消除了这行代码的泄漏问题：
loop {@x=callcc{|c|c}}
还消除了我们多线程机器人技术应用中的泄漏问题。过去我们所使用的Ruby进程在运行一天后常常达到20+MB，而现在已经降到了10MB以下。

正如其所示，泄漏是由GCC的优化所导致的：它与Ruby的旧式GC的交互很差劲：

垃圾收集器的内存泄漏问题并不是它本身的错误。问题在于“C”机器栈（machine stack）中充满了对象引用。其主要原因是由于gcc编译器创建了过多大的stack frame而又没有对其初始化。用在Ruby解释器的核心递归表达式程序中的某些“C”构造会生成特别大而又稀疏的stack frame。函数rb_eval()就是最差劲的一个，它会为每次调用都创建KB大小的stack frame，而其又会调用自身几百次。这导致栈的容量急剧膨胀，经常充满了不再使用而又无法移除的对象引用。

Brent提供了一些修复（针对Ruby 1.8.7-patlevel72），目的在于解决这些问题。

当运行在真实世界的Rails应用上时，测试报告表明该修复对速度的提升效果很明显。同时也报告了一些问题，让我们对其拭目以待吧。

这些修复是开源（Ruby）社区对MRI改进的又一个证明。Mod_rails (或REE)已经是一个佐证了，它使得MRI的垃圾收集器更加友好（参见相关新闻以了解更多）。

MRI的性能在很大程度上取决于它的编译方式。

今年你还打算继续使用Ruby 1.8.x么？如果是的话，理由呢？

查看英文原文：New Patches for 1.8.x Fix Memory Leaks And Improve Performance

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

1. 返回顶部

   这篇文章写的错误百出

   发表人 Fan Robbin

   内存泄漏问题根本就不是GC优化导致的，而是幽灵指针引起的。
   
   Brent Roman的MBARI patch也并非只能用在1.8.7上面，一旦该补丁被合并到trunk以后，他会后续提交1.9.1的patch。
   
   这篇文章错误太多了，简直就是误导。看看我写的介绍吧：
   
   ruby内存泄漏的罪魁祸首 - 幽灵指针
   
   解决ruby内存泄漏的超级大补丁发布啦

   回复

2. 返回顶部

   Re: 这篇文章写的错误百出

   发表人 Guo Xiaogang

   注意没有人说是“GC优化导致的”，文中说的是“GCC优化”。可能大写有误导吧。
   
   所谓“gcc optimizations”我想是指
   
   

   
   [...]gcc compilers create overly large stack frames and do not initialize many values in them[...]
   

   
   你所说的“幽灵指针”不就是来自这些没初始化的stack frames。这种做法最后怎么变成内存泄漏，你已经解释得很清楚。Brent的补丁说明里面也介绍得很清楚。

   回复

3. 返回顶部

   Re: 这篇文章写的错误百出

   发表人 Guo Xiaogang

   差点忘了谢谢Robbin Fan。
   
   多谢补充这两篇出色的介绍和1.9.1补丁的信息。

   回复

• 更早的 >