I have installed Redmine on cent-os. I have configured it on Apache with Passenger .And It s been used by hardly 400 people. At the particular point of time ,Ruby Process eats to much of memory. Almost 100% of the memory .
I am not able to see from where the leakage is going on in the ruby process. Just can see in the top ruby is reaching to 90% and some times more then 99%.
Is there any way to solve the issue. Any Deployment solution there or any way to check where is the process leakage in ruby code?
Here are some details of the version I am using on RVM
gem -v
1.8.24
ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
rails -v
Rails 2.3.14
Maybe you can follow the tips in this article: http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-with-frozen-processes-on-unix/
Related
I have been going through a Ruby on Rails tutorial and have been succeeding up until this point. I simply try to run the rails console:
rails console
and I get this message:
/home/george/.rvm/gems/ruby-1.9.3-p448/gems/nokogiri-1.6.0/lib/nokogiri/nokogiri.so: [BUG] Segmentation fault
ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]
Obviously, I have tried other solutions on StackOverflow, including
sqlite3_native.so: [BUG] Segmentation fault
and Rails s return: [BUG] Segmentation fault
and have tried the various solutions, such as completely reinstalling the bundles and gems, and removing and reinstalling different versions of sqlite3, none of which have had any effect.
I'm just looking for suggestions or things I'm missing as a newbie to both Ruby and Rails.
[Edit/Solution] Sometimes I worry about my own intelligence. All of my problems were solved by using RVM to switch to 1.9.3-p448 and setting this is as default.
The first thing that jumps out at me is it is trying to load a Ruby 1.9.3 version of the nokogiri library in a Ruby 1.8.7 environment. This would most likely be compiled against all sorts of things that conflict with Ruby 1.8.7 (different versions of libxml2, etc). If I were you, I would nuke 1.8.7 from your machine entirely, and focus on getting a totally sane RVM environment running 1.9.3, since it seems that is what you are actually trying to accomplish anyways.
This probably has to do with the GEM_LOAD_PATH conflicting between the 2 different versions of ruby. Nuking one or the other is probably your best bet.
I have two rails projects on my machine. If I go directly to one of the apps and run the rails s, I get a seg fault error (below).
.rvm/gems/ruby-1.9.3-p194/gems/bcrypt-ruby-3.0.1/lib/bcrypt_ext.bundle: [BUG] Segmentation fault
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]
However if I run the other project first, then run this project, the problem goes away and the server boots up. Anyone know why this would happen or have any ideas that I could try?
I have a feeling it has to do with bundler and potentially rvm with managing gems?
It says it is a bug, and you are using an outdated patchlevel from ruby.
Try to update to the latest patch level (I believe ruby-1.9.3-p429), and if it persists and you really trust your hardware, you will have to open a bug for ruby.
Could be computer memory issue too, I suppose it is better try your code in other box, just to be sure.
The Ruby Version set on my windows machine is:
ruby 1.9.3p392 (2013-02-22) [i386-mingw32]
I have tried running the ruby installer for Ruby 2.0.0 but cannot seem to get it to replace the 1.9.3p392.
Now I am working in a tutorial that requires the gem 'monbon' - but when I run bundle on a new app, I get the message:
Could not find gem 'monbon' (= 0.0.6) x86-mingw32' in the gems available on this machine.
Is the patch on the Ruby causing this error and why?
What are some steps I can take to just run Ruby 1.9.3 or 2.0.0?
Any further code or screen shots I can take to help diagnose issue?
EDIT TO ADD SOLUTION:
I was able to install Pik
(https://github.com/vertiginous/pik)
by following this tutorial
(http://puneetpandey.com/tag/how-to-install-and-configure-pik-on-windows/)
and solving an error by this stack overflow questions (installing pik in system path in windows)
Then I installed Ruby 2.0.0 and also the exact Ruby version and patch from the tutorial using Pik.
Firstly, this 'strange patch' is perfectly normal and expected. It tells you the patchlevel that has been applied to your ruby 1.9.3 installation. And patches are good - they generally are used to fix security and stability issues.
Secondly, the [i386-mingw32] is there to let you know that you are using the Windows flavor (or 'i386-mingw32' flavor to be more correct) of ruby. This is important, because not all gems necessarily support all OS's without some tweaking. Many of them need to be compiled, and the instructions for doing so can differ from OS to OS. Now on to your list:
The strange patch is not causing the error.
The steps you can take to run the correct Ruby are - install pik. It lets you choose the right version of ruby whenever you want. And it lets you set the default version when you don't want to think about it.
Nothing to diagnose, everything is running as expected. The gem can't be found for the i386-mingw32 ruby flavor. Check with your 'monbon' gem author to see if and how this can be resolved.
TLDR: How do I force a rails app to use the correct ruby interpreter?
Hello,
Something hosed parts of my Ruby 1.9.2p290 install (certain classes just went missing one day), so I removed it and attempted to reinstall the environment.
I'm running on Snow Leopard.
Ruby 1.9.2 was installed from source. (I tried to install via MacPorts and it would fail). I am not keen on RVM as I use bundler and I seem to recall some problems with how bundler and RVM interact, though from what I can tell RVM works.
After reinstalling a few gems I noticed they were being placed in a gem folder for Ruby 1.8. "This is weird," I thought.
Starting up the rails app, I notice a lot of weird exceptions being thrown regarding syntax. After printing RUBY_VERSION to stdout, I noticed that the Rails app is running 1.8.7.
which ruby shows only one ruby interpreter:
$ which ruby
/usr/bin/ruby
$ /usr/bin/ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
If I open up Activity Monitor, the ruby process from the Rails app lives at /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby, which I believe is the ruby interpreter that OSX shipped with.
I haven't found any information on completely purging Ruby from OSX. I would love to do that then simply install ruby from source.
It seems there are two problems:
Rails is running a ruby interpreter that I have no idea how it is calling, when I need it to run the 1.9.2 interpreter installed from source
gems are being installed in a 1.8 folder, I suspect because gem thinks its running under 1.8
How do I fix this?
Thank you,
Tom
I guess the best way to overcome this issue is using rvm to handle your Ruby and Rails environments through 'gemset's.
I had the same issue and I use gemsets now without a problem.
This is the article which I got things working:
http://stjhimy.com/posts/10-five-quick-steps-to-set-up-rvm-with-rails-2-and-rails3
I just got my rails 2.3.8 app running on ruby 1.9.1. To get into the console, start the webserver, anything that initializes rails, takes 3 - 4 times longer in ruby 1.9 than in ruby 1.8.7. I'm using ruby version managers so I can easily switch between ruby 1.9 and ruby 1.8.7. The speed difference happens in both production and development. I want to use 1.9 because its must faster once everything is running, but the startup time is so bad the app is timing out on Heroku on the first request.
Any ideas why ruby 1.9 would be 3 - 4 times slower? I can't figure it out for the life of me.
Try using 1.9.2-head instead of 1.9.1. It is the recommended version for Rails 3, so you may have better luck. Rails 2.3.8 starts up very quick on 1.9.2-head from the tests I just ran locally (with Authlogic installed too, btw).
If you are using RVM, type the following:
rvm install 1.9.2-head
rvm use 1.9.2-head
Edit: I tried 1.9.1 p378 with the same app and the start up time took about 13 seconds compared to 5 seconds on 1.9.2-head. 1.9.2-rc1 is due out this month I believe, so that's good news :)
It's probably because ruby 1.9 uses gem_prelude (which gives you a large load path) instead of normal rubygems. Checkout the length of $: -- that gets searched once for each require, causing extra time
If you want it the old way, (upgrade to the latest version of rubygems and) run ruby --disable-gems
If you are on windows, take a look into my faster_require gem.
http://github.com/rdp/faster_require
Though I suppose, now that you mention it, it might help in 1.9 Linux. Maybe.
GL!
-rp