OSX 上的 Ruby 进程持续运行在 90% 以上。怎么了？
我正在本地构建一些 Ruby/Rails 应用程序。我最近注意到，无论我正在开发哪个应用程序，我的 Ruby 进程都会构建到 90% 以上，CPU 风扇会启动，除非我杀死傻瓜，否则不会停止它。我正在开发哪个应用程序似乎并不重要。有什么想法吗？有什么办法可以跟踪出了什么问题吗？
我在 Mongrel、Apache/Passenger 和 POW 上运行过这些应用程序，每次都得到相同的结果。
顺便说一句，我没有任何持续运行的工作或任务。这种 CPU 占用现象是在服务器没有受到影响的情况下发生的。
我的系统：
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
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过打开终端窗口并运行
top，或者打开Activity Monitor，然后单独运行每个窗口并查看 CPU 何时开始攀升？top和Activity Monitor都可以让您按应用生成的 CPU 负载进行排序。使用 top -o cpu 并观察最高负载是否是您运行的应用程序，或者可能是该应用程序导致运行的其他内容。Rails 应用程序在启动时会出现峰值，但在等待传入连接时应该稳定下来。如果您正在执行周期性任务，您应该会看到这些任务会导致 CPU 活动再次激增，然后在任务结束时下降。
您使用的是 MacBook Pro。你有多少内存？也许您的应用程序运行速度较低并且不得不交换太多内容？这会影响您的整体系统性能，使 CPU 工作更加困难，导致其发热。 MacBook Pro 的硬盘是为电池效率而不是高性能而设计的，因此，如果您使用大量数据库 I/O 来重击磁盘，则可能会导致机器升温并导致应用程序因记录锁定而等待或某种争论。
有很多不同的事情可能会导致你的机器和应用程序变慢，而你并没有真正给我们提供很多可以处理的东西，所以这些是我要研究的一些一般想法。
Have you tried opening a terminal window and running
top, or openingActivity Monitor, then running each one individually and seeing when your CPU starts to climb? BothtopandActivity Monitorwill let you sort by the CPU load an app is generating. Usetop -o cpuand 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.
我也注意到了这一点，并且能够确定它。如果我运行 top -o cpu，然后打开另一个终端窗口并运行 IRB，然后关闭终端窗口而不退出 IRB，然后突然 top 显示ruby 进程的 CPU 占用率约为 90%。如果我做同样的实验，但在关闭窗口之前退出 IRB，则不会出现 90% ruby hog。
因此，显然我们需要小心不要关闭终端窗口，除非我们已经正确退出 ruby 程序。
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.
这可能更多的是建议而不是答案，因为我不知道它是否涵盖您的问题，但只需几分钟，您可能想尝试一下。
我在 FreeBSD 上遇到过这个问题，这是我的解决方案。不知何故，Ruby / Rails / 等的版本彼此不兼容，而且它们也没有给我提供我可以随时追查的错误消息。
我确信您正在这样做，但请确保您的捆绑包始终是最新的。
我切换到了rvm（Ruby版本管理器），并完全停止使用系统Ruby。总的来说，这是我使用 Ruby 所做的最好的系统管理举措，因为 Mac OS X / Macports（我的开发机器）和 FreeBSD / ports（我的生产机器）在 Ruby 版本中远远落后。
我可以看到您在 Mac OS X 上的 ruby 1.8.7 补丁级别为 174——当前版本的补丁级别为 330 或更高。
此外，如果您要推送到不是 Mac OS X 的生产服务器，那么您就是使用 RVM 可能会获得更好的可移植性，因为您可以在两台机器上安装相同版本的 Ruby、Rails 和所有 gem。
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.