解决ruby内存泄漏的超级大补丁发布啦

31顶
1踩

2008-12-22 12:40 by 见习编辑 robbin 评论(12) 有8847人浏览

Ruby

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

JavaEye在12月初发布了新闻ruby内存泄漏的罪魁祸首 - 幽灵指针，介绍了当前Ruby解析器内存泄漏的根本原因，并且透露了Brent Roman正在打算给ruby提供补丁程序解决内存泄漏问题。

如今Brent Roman的超级大补丁终于发布！该超级大补丁命名为：“1.8.7-p72 MBARI Patch”。因为这个补丁是给Ruby当前最广泛使用的生产环境的版本ruby 1.8.7-p72版本提供的，而Brent Roman本人在Monterey Bay Aquarium Research Institute工作，因此该补丁被成为MBARI patch。

MBARI补丁总共包含了6个补丁文件，他们分别是：

1、MBARI1.patch：修复Ruby多线程Continuations的bug导致的段地址错误和内存泄漏
2、MBARI2.patch：修改Ruby多线程的栈帧分配策略，解决多线程栈帧分配策略导致的内存泄漏
3、MBARI3.patch：修复幽灵指针造成的Ruby内存泄漏。
4、MBARI4.patch：修复Ruby的eval()方法调用造成的大量内存泄漏
5、MBARI5.patch：修复Ruby的异常处理的代码跳转造成的内存泄漏
6、MBARI6.patch：提供了Method和Proc对象的source_location()方法

根据Brent Roman自己对ruby自带的测试套件测试的结果表明，应用该补丁以后，内存泄漏问题有极大改善。

       版本                     初始内存    结束内存       耗时
未打补丁1.8.7-p72:      30MB             97MB         92 seconds
打了补丁1.8.7-p2:        30MB            57MB        100 seconds

该测试套件执行完毕以后，内存占用从97MB下降到57MB，效果十分明显！

目前MBARI Patch还处于alpha阶段，Brent Roman本人的开发环境是Linux 32bit，GCC 4.3.2，他呼吁更多人帮助他测试该补丁文件，在各种不同环境下测试，向他提交bug，便于他更好的完善这个内存泄漏补丁。

安装MBARI补丁很简单：

1、下载ruby 1.8.7-p72，并且解压缩
2、下载MBARI补丁，并且解压缩
3、执行命令：MBARIp72patches/apply ruby-1.8.7-p72 打补丁
4、编译ruby

CFLAGS="-O2 -fno-stack-protector -mpreferred-stack-boundary=2" ./configure
make && make install

如果是gcc3.3版本，要去掉 -fno-stack-protector编译参数；如果是64位机器，-mpreferred-stack-boundary=4才行。

然后 ruby -v 应该显示：

1.8.7 MBARI 6 on patchlevel 72

应用该补丁在JavaEye服务器上面简单的测试对比如下：

ruby 1.8.7 p72 fcgi进程占用物理内存129MB
ruby 1.8.7(gc patch) fcgi进程占用物理内存176MB
ruby 1.8.7 MBARI fcgi进程占用物理内存99MB

效果还是比较明显的，详细的性能测试报告请看：

ruby MBARI大补丁性能评测报告

分享到：

31
顶

1
踩

评论共 12 条请登录后发表评论

12 楼 wosmvp 2008-12-23 09:18

就等

引用

让大家去实际测试了

11 楼 tangyuanjian 2008-12-22 21:19

1.86可以打嘛？

10 楼 hozaka 2008-12-22 20:31

PPC, Mac OS X 10.5.6 下提示 preferred-stack-boundary 无效参数……

9 楼庄表伟 2008-12-22 19:49

嗯，继续等待更大的合并后补丁

8 楼 robbin 2008-12-22 18:03

花花公子写道

这个和ruby GC的补丁一起作用的效果不知道会怎么样。

两个不能同时打，否则打不上，我已经给Brent写了邮件，建议他的patch把Railsbench的GC patch给merge进来，哈哈。我们等好消息吧。

7 楼 robbin 2008-12-22 18:02

mccxj 写道

注意到这句了。。。Note that some older versions of gcc did not support (or need) the -fno-stack-protector option.It should be omitted from the CFLAGS= in this case.

我给Brent发了邮件，他回复说gcc3.3不需要 -fno-stack-protector，默认就是disable的，去掉它编译就好。

现在的问题是64位机器上"-mpreferred-stack-boundary=2"这个参数是不行的，必须是4。我已经报告给Brent了，等他解决吧。不过即使是这样，我用JavaEye网站代码的Rails测试结果表明，内存占用有非常明显的下降。

接下来等我有空再测试一下执行性能的影响，如果都没有问题，我就准备上到JavaEye网站服务器，让大家去实际测试了，哈哈。

6 楼花花公子 2008-12-22 17:26

这个和ruby GC的补丁一起作用的效果不知道会怎么样。

5 楼花花公子 2008-12-22 17:25

robbin 写道

花花公子写道64位编译的时候报错误 -mpreferred-stack-boundary=2 必须在4～16当中，用了4感觉没什么改善。你怎么测试是否有改善？

没有测试，全靠感觉。可以考虑进行大规模并发测试，看看测试进行中mongrel或者fcgi重启次数。如果测试没有跑到内存泄露非常严重的地方，也会看不出什么结果。

4 楼 mccxj 2008-12-22 17:08

注意到这句了。。。
Note that some older versions of gcc did not support (or need) the -fno-stack-protector option.
It should be omitted from the CFLAGS= in this case.

3 楼 mccxj 2008-12-22 17:05

在gcc3.4.6 configure过不去。。。继续调整

2 楼 robbin 2008-12-22 16:11

花花公子写道

64位编译的时候报错误 -mpreferred-stack-boundary=2 必须在4～16当中，用了4感觉没什么改善。

你怎么测试是否有改善？

1 楼花花公子 2008-12-22 14:28

64位编译的时候报错误 -mpreferred-stack-boundary=2 必须在4～16当中，用了4感觉没什么改善。

发表评论

您还没有登录,请您登录后再发表评论

31顶1踩