this might sound like a rant, but i'm just desperate
i was running my app with ruby 1.8.5p52 for quite a while and the
mongrel processes were quite memory stable as well as the dRB process
for ferret.
the latest security problem wasn't much of an issue since the app only
runs in an intranet environment.
i now tried 1.8.5p231 (the last stable i could find from the 1.8.5
series) because of some supposedly fixed memory leak in "eval" which i
need for a service to peridodically execute some tasks for my RoR app.
e.g.
1000.times {|i|eval("a#{i} = 1")}
leaked memory like hell in 1.8.5p52
while in 1.8.5p231 it seemed totally stable (at least for that snippet).
so i updated the server with that 1.8.5p231 version.
but sadly my service is still leaking memory. even worse: now all
mongrels and the ferret service also leak memory like mad. (each mongrel
eating 300+mb after just 12 hours).
isn't there any memory stable ruby version for windows?
or at least is there a way to reset a ruby process and make it start
itself over? normally i'd be totally against such methods, but since
ruby itself can't run stable i see no other way
PS:
upgrading to RoR 2.x or
moving to Linux is out of the question (trust me, i would if i could)
isn't there any memory stable ruby version for windows?
There almost is
the mingw version is faster:
you can see if it doesn't leak.
If it still does I could possibly build you a 187 with the MBARI patches
for mingw. It might work [the MBARI patches helped me overcome a leak]
-=r
···
or at least is there a way to reset a ruby process and make it start
itself over? normally i'd be totally against such methods, but since
ruby itself can't run stable i see no other way
PS:
upgrading to RoR 2.x or
moving to Linux is out of the question (trust me, i would if i could)
isn't there any memory stable ruby version for windows?
There almost is
the mingw version is faster: Still playing with Ruby on Windows | AkitaOnRails.com
you can see if it doesn't leak.
If it still does I could possibly build you a 187 with the MBARI patches
for mingw. It might work [the MBARI patches helped me overcome a leak]
thanks alot for pointing that out!
i didn't knew there were such ugly problems with ruby just because it
was compiled with VC6. :S
downloaded and installed it today. had to fix 1 or 2 minor glitches in
the app to get it working with 1.8.6.
still too early to say s.th. but looks promising so far.
1.8.7 sadly doesn't work with rails 1.2.x. but out of interest...
that sounds pretty interesting, it's just that i tried 1.8.7 2 weeks ago
and it didn't work. i kept trying until i somewhere read that 1.8.7
would only work with rails 2.x.
but if you have a binary somewhere i'd give it a try. isn't there any
1.8.6 version with those patches? (especially Patch 3 and 4 sounds
good).
so far the 1.8.6 i'm testing atm seems to be more stable than every
version i ever had. sadly my service still seems to eat a few KB per
hour. not as bad as before, but a leak of 15M per day is still not
acceptable
that sounds pretty interesting, it's just that i tried 1.8.7 2 weeks ago
and it didn't work. i kept trying until i somewhere read that 1.8.7
would only work with rails 2.x.
but if you have a binary somewhere i'd give it a try. isn't there any
1.8.6 version with those patches? (especially Patch 3 and 4 sounds
good).
There's a branch that has 1.8.6 with the patches. I believe it's stable
though it hasn't seen as much work as the 1.8.7 line.
here's some refs:
how to build mingw from scratch:
[run rake]
look at the other branches.
I may be able to come up with a binary.
-=r
cool, guess i have to get git after all. (i'm still a SVN user)
and don't have any compiler on my XP vmware installation yet.
so i suppose i need to spent some time first to install everything
before i can try that. PITA!
i wonder if it would work to cross-compile from OSX.
but i'll have some extra spare time next weeks anyway, so i now know how
to spend it
and don't have any compiler on my XP vmware installation yet.
so i suppose i need to spent some time first to install everything
before i can try that. PITA!
Thanksfully with the oneclick mingw installer you download it and run
rake and it downloads the compiler for you, then uses it to build ruby
i wonder if it would work to cross-compile from OSX.
i have no experience with git, i just did this:
git clone git://github.com/oneclick/rubyinstaller.git
cd rubyinstaller
rake
but the promise of just typing "rake" was too good to be true
yeah the main git repo has some bugs currently.
My fork fixes them http://github.com/rogerdpack/rubyinstaller/tree/master
do rake -T to see how to use it.
I'd also be interested to see if the CHECKOUT=1 MBARI=1 option works or
not.
Thanks!
-=r
···
guess i need some specific tag/branch/revision i don't know yet. have to
dig into git and figure that out first.
couldn't see any errors, last output was a large textblock about
rubygems-update.
so how do i proceed to get a proper ruby directory out of it?
i don't really want/need an installer msi.
Wow way to go. I started mine building yesterday and the internet is so
slow at work that it hasn't finished downloading from github LOL.
I'm not sure what to do after you build it--you could try rake package
then install the generated package, or you could search for and run
ruby.exe [which is what I typically do]. The only problem with that is
that rubygems is installed in a "separate, side by side" folder, so if
you want to run it from where it's built you'll need to either copy the
rubygems folders' contents into the ruby_mingw directory, or reinstall
rubygems.
Let me know how it goes. Should it work you'll be the first person ever
to have built and run the 1.8.6 MBARI patches on windows.
C:\tmp\git\rubyinstaller\sandbox\ruby_test\bin>.\ruby.exe -e puts('Hello
World!')
.\ruby.exe: no such file to load -- ubygems (LoadError)
Yeah I'd probably download their .zip install file then ruby "ruby
setup.rb" on them. Either that or somewhere there's something akin to a
sandbox\rubygems folder that you have to copy "over" the ruby_test
directory.
GL.
-=r
"You don't have permission to access
/ruby/installs/ruby-186-p287-mbari.msi on this server."
the file permissions seem to be wrong.
but i've installed .NET3.5 now and was able to build the .msi
installer(s) myself.
some quick testing showed the following behavior:
- initial memory load seems to be much higher than mswin32 builds
"ruby script/console" uses around 70-75 MB while the mswin32 build
just grabbed 40-42 MB.
- installed gems don't seem to play nice with the mingw32 build. while i
was able to install a compatible mongrel build, the mongrel_service gem
seems not to be compatible at all.
i can start mongrel on console via "ruby script/server -e production"
but when trying to start as a service it just crashes and tries to start
over and over and over...
- memory consumption over time is hard to tell so far, but my guess is
that it is marginally better than the official stable OCI build.
"You don't have permission to access
/ruby/installs/ruby-186-p287-mbari.msi on this server."
k fixed those and uploaded a copy that has the devkit with it
Sorry.
the file permissions seem to be wrong.
but i've installed .NET3.5 now and was able to build the .msi
installer(s) myself.
some quick testing showed the following behavior:
- initial memory load seems to be much higher than mswin32 builds
"ruby script/console" uses around 70-75 MB while the mswin32 build
just grabbed 40-42 MB.
- installed gems don't seem to play nice with the mingw32 build. while i
was able to install a compatible mongrel build, the mongrel_service gem
seems not to be compatible at all.
yeah mingw is cutting edge so not all gems are yet compatible with it.
It would be interesting to look into it and try and see why.
I'm not sure why it would start with higher memory use. Make sure
you're not using p355 which has a memory leak
Does yours use 100% cpu when you are in script/console? [or irb, for
that matter]?
Thanks!
-=r
k fixed those and uploaded a copy that has the devkit with it
Also note that I "nuked and rebuilt" my github/rubyinstaller
repository[1] today, so that the commits would be cleaner, so git pull
will be unreliable until reclone it.
Also, if you get a stackdump with STATUS_ACCESS_VIOLATION using msysgit
you need a newer copy of msys-1.0.dll [2]
