Bill K. wrote:
From: “Pete H.” [email protected]
ruby -v gives:
ruby 1.8.6 (2008-06-20 patchlevel 230) [i386-linux]
patchlevel 230 was one of the bad ones. It leaks like a sieve.
See [ruby-core] thread:
[Ruby 1.8 - Bug #216] Memory leaks in 1.8.6p230 and p238
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17571
It affected a whole range of patchlevels:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17596
Also, a leak of similar severity was introduced later on, starting
in p296 lasting at least through p355:
[ruby-core:22582] Re: [Bug #1223] Memory leak reintroduced in 1.8.6
branch?
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/22852
I’d recommend trying the recent official 1.8.6 release, p368
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/332578
I have not personally tried p368 on my long-running servers, as
I had already found a stable version, p279. So I have not had a
need to upgrade the version. I can say that p279 is very stable
in its memory profile. I’m guessing the official p368 release
probably is too.
Hope this helps,
Bill
Great info Bill, thanks so much. I’ll try building 1.8.6-p368 and see if
the same component exhibits different behaviour running under that
build.
Assuming that helps, does anyone have any pointers on putting a
non-standard ruby rpm onto a centOS box? My company use centos in
production and I’m betting that my Ops guys will want an rpm, official
or otherwise.
From: “Pete H.” [email protected]
Assuming that helps, does anyone have any pointers on putting a
non-standard ruby rpm onto a centOS box? My company use centos in
production and I’m betting that my Ops guys will want an rpm, official
or otherwise.
I’ve not tried it, but checkinstall is supposedly able to capture
whatever
“make install” would do, and then “create a Slackware, RPM or Debian
compatible package and install it using your distribution’s standard
package administration utilities.”
http://checkinstall.izto.org/docs.php
Hope this helps,
Bill
Pete H. wrote:
Bill K. wrote:
From: “Pete H.” [email protected]
ruby -v gives:
ruby 1.8.6 (2008-06-20 patchlevel 230) [i386-linux]
patchlevel 230 was one of the bad ones. It leaks like a sieve.
See [ruby-core] thread:
[Ruby 1.8 - Bug #216] Memory leaks in 1.8.6p230 and p238
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17571
It affected a whole range of patchlevels:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17596
Also, a leak of similar severity was introduced later on, starting
in p296 lasting at least through p355:
[ruby-core:22582] Re: [Bug #1223] Memory leak reintroduced in 1.8.6
branch?
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/22852
I’d recommend trying the recent official 1.8.6 release, p368
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/332578
I have not personally tried p368 on my long-running servers, as
I had already found a stable version, p279. So I have not had a
need to upgrade the version. I can say that p279 is very stable
in its memory profile. I’m guessing the official p368 release
probably is too.
Hope this helps,
Bill
Great info Bill, thanks so much. I’ll try building 1.8.6-p368 and see if
the same component exhibits different behaviour running under that
build.
Assuming that helps, does anyone have any pointers on putting a
non-standard ruby rpm onto a centOS box? My company use centos in
production and I’m betting that my Ops guys will want an rpm, official
or otherwise.
I’ve ran the same component side by side on both p230 and p368 for a few
hours. The p368 component is holding steady at around 19MB, while the
p230 component is up to 83MB resident, 98MB virtual. Looks like the
culprit was indeed a leaky interpreter.
Bill, thanks so much for pointing me in such a fruitful direction.
I guess my solution will be to upgrade our production machines to the
new p368 build.
Cheers,
Pete