阅读更多

31顶
1踩

编程语言

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

2008-12-22 12:40 by 见习编辑 robbin 评论(12) 有8888人浏览
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感觉没什么改善。

发表评论

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

相关推荐

Global site tag (gtag.js) - Google Analytics