如何减少 Linux 中 Rails 3 命令的用户时间与系统时间的比率
我目前在 Ubuntu Linux 上运行 Rails 3,对于简单的命令,我的响应时间似乎非常长。例如,如果我调用 db:rollback 来删除一个 4 列 0 行的小表,大约需要 30 秒。
paul@paul-laptop:~/rails_projects/foglift$ time rake db:rollback
(in /home/paul/rails_projects/foglift)
== CreateResults: reverting ==================================================
-- drop_table(:results)
-> 0.0013s
== CreateResults: reverted (0.0014s) =========================================
real 0m27.946s
user 0m26.570s
sys 0m1.284s
用户时间与系统时间的高比例让我感到困扰。有办法诊断或解决这个问题吗?
任何帮助将不胜感激。
谢谢! 保罗
I'm currently running Rails 3 on Ubuntu Linux and I'm getting what seems like really long response times for simple commands. For instance if I call db:rollback to drops a tiny table of 4 columns and 0 rows takes ~30 seconds.
paul@paul-laptop:~/rails_projects/foglift$ time rake db:rollback
(in /home/paul/rails_projects/foglift)
== CreateResults: reverting ==================================================
-- drop_table(:results)
-> 0.0013s
== CreateResults: reverted (0.0014s) =========================================
real 0m27.946s
user 0m26.570s
sys 0m1.284s
The high ratio of User time to Sys time is what's bothering me. Is there away to diagnose or troubleshoot this?
Any help would be most appreciated.
Thanks!
Paul
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你真的无法改变这一点。这是使用解释性语言和强大/灵活的 Web 开发框架的结果。
当您运行该命令时,必须先加载 ruby 解释器以及 Rails 环境和您的应用程序,然后才能运行回滚。它类似于启动 Rails 服务器然后运行回滚。
这在构建时可能会很痛苦,但也有优点。您的迁移可以包含利用应用程序中的类来做出如何执行迁移的正确决策的逻辑。到目前为止,长期可维护性是更大的好处。
另外,DB型号一般不会经常更换,动力比超高速更重要。
You really won't be able to change this very much. This is a result of using an interpreted language and a powerful/flexible framework for web development.
When you run the command the ruby interpreter has to be loaded along with the rails environment and your application before it can run the rollback. It is similar to starting up the Rails server and then running the rollback.
This may be painful when building, but there are advantages as well. Your migrations can contain logic utilizing classes from your app to make the right decisions of how to execute the migrations. Long term maintainability is by far the greater good here.
Also, DB models usually don't change frequently, the power is more important than super speed.