Reputation: 111
I have a handful of Ruby/Rails apps I'm building locally. I've noticed lately that no matter which app I'm working on, my Ruby process will build up to 90+%, the CPU fan will kick on, and there's no stopping it unless I kill the sucker. Doesn't seem to matter which app I'm working on. Any ideas? Any way to track what's wrong?
I've run the apps on Mongrel, Apache/Passenger, and POW, and every time I get the same result.
And BTW I don't have any jobs or tasks running constantly. This CPU hogging is happening without the servers being hit.
My system:
Ruby: ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] Rails: Rails 3.0.4 OSX 10.6.7, MBP 2.53 GHz Core 2 Duo
Upvotes: 4
Views: 10495
Reputation: 9752
I have noticed this also and was able to pin-point it.. If I run top -o cpu, and then open another terminal window and run IRB, and then close the terminal window without exiting out of IRB, then suddenly top shows a ruby process at around 90% CPU. If I do the same experiment but exit out of IRB prior to closing the window, there is no 90% ruby hog.
So, apparently we need to be careful to not close terminal windows unless we have properly exited out of ruby programs.
Upvotes: 3
Reputation: 160611
Have you tried opening a terminal window and running top
, or opening Activity Monitor
, then running each one individually and seeing when your CPU starts to climb? Both top
and Activity Monitor
will let you sort by the CPU load an app is generating. Use top -o cpu
and watch to see if the highest load is the app you ran or maybe something else the app is causing to run.
A Rails app will spike when it starts up but should settle down as it waits for incoming connections. If you have periodic tasks it's performing you should see those cause the CPU activity to spike again then drop when the task ends.
You're on a MacBook Pro. How much RAM do you have? Maybe your apps are running low and having to swap out too much? That would affect your overall system performance making the CPU work harder, causing it to heat up. A MacBook Pro's hard disk is designed for battery efficiency, not high performance, so if you're hitting the disk hard with a lot of database I/O, you could be heating the machine up and causing the apps to wait due to record locking or some sort of contention.
There's a lot of different things that can cause your machine and apps to slow down, and you haven't really given us a lot to work with, so those are some general ideas of what I'd look into.
Upvotes: 4
Reputation: 503
This might be more of a suggestion than an answer, because I don't know if it covers your issue, but it takes just a few minutes, and you might want to try it.
I have had this problem on FreeBSD, and here was my solution. Somehow, the versions of Ruby / Rails / etc were not compatible with one another, and they also did not give me error messages I could always chase down.
I'm sure you are doing this, but make sure your bundle is always up-to-date.
I switched to rvm (Ruby Version Manager), and stopped using system Ruby altogether. This was overall the best sysadmin move I made with Ruby, because Mac OS X / Macports (my dev machine) and FreeBSD / ports (my production machine) are way behind in Ruby versions.
I can see that you are at ruby 1.8.7 patchlevel 174 on Mac OS X -- the current version's patchlevel is somewhere at or above 330.
Moreover, if you are pushing to a production server that's not Mac OS X, then you're going to probably get better portability with RVM, because you can install the same versions of Ruby, Rails, and all gems, on both machines.
Upvotes: 0