gpt4 book ai didi

ruby-on-rails - Rails、Minitest 和 Guard - 为什么 rb-fsevent 占用了超过 100% 的 CPU?

转载 作者:数据小太阳 更新时间:2023-10-29 06:56:22 26 4
gpt4 key购买 nike

我在我的 Rails 应用程序中运行守卫,测试套件(最小的)最近停止正常工作。

如果幸运的话,它会运行所有测试一次,也许两次。在那之后,即使是一个小的测试文件被更改也需要很长时间才能响应,以至于使用 gem 变得徒劳无功。

在测试运行时跟随 top,我可以看到有一个 ruby​​ 进程持续占用了超过 100% 的 CPU。即使所有测试都已运行并且我没有对文件进行任何更改。

Output from top

ruby 进程是:

/Users/Bodacious/.rvm/gems/ruby-2.0.0-p247@MyApp/gems/rb-fsevent-0.9.3/bin/fsevent_watch --latency 0.1 /Users/Bodaiou/Clients/MyApp

(进程 31332)在所附的屏幕截图中。

ruby 2.0.0-p247

这是我的设置:

# Gemfile (with irrelevant gems removed)
gem 'rails', '4.0.0'
group :test do
gem 'launchy'
gem "mocha", require: false
gem 'database_cleaner'
gem 'selenium-webdriver'
gem 'capybara-webkit' # for headless javascript tests
gem 'timecop'
gem "minitest-focus"
end

group :development, :test do
gem "minitest-rails"
gem "minitest-rails-capybara"
gem 'zeus'
gem 'guard'
gem 'guard-minitest'
gem 'factory_girl_rails'
end


# Guardfile
guard :minitest, all_on_start: false do
# Rails 4
watch(%r{^app/(.+)\.rb}) { |m| "test/#{m[1]}_test.rb" }
watch(%r{^app/controllers/application_controller\.rb}) { 'test/controllers' }
watch(%r{^app/controllers/(.+)_controller\.rb}) { |m| "test/integration/#{m[1]}_test.rb" }
watch(%r{^app/views/(.+)_mailer/.+}) { |m| "test/mailers/#{m[1]}_mailer_test.rb" }
watch(%r{^lib/(.+)\.rb}) { |m| "test/lib/#{m[1]}_test.rb" }
watch(%r{^test/.+_test\.rb})
watch(%r{^test/test_helper\.rb}) { 'test' }

ignore(%r{^tmp/})

end

# test_helper
ENV["RAILS_ENV"] = "test"
require File.expand_path("../../config/environment", __FILE__)

require 'rails/test_help'
require 'minitest/autorun'
require 'minitest/pride'
require "minitest/rails/capybara"

require "mocha/setup"

# Sidekiq https://github.com/mperham/sidekiq/wiki/Testing
require 'sidekiq/testing'
Sidekiq::Testing.fake!

Dir[Rails.root.join('test', 'support', '*.rb')].each do |file|
require file
end


class MiniTest::Spec
include FactoryGirl::Syntax::Methods
include AllTestHelper

end


class ActiveSupport::TestCase
include FactoryGirl::Syntax::Methods
include AllTestHelper
end

class Capybara::Rails::TestCase
include Rails.application.routes.url_helpers
include Capybara::DSL
include Capybara::Assertions
include IntegrationTestHelper

# Called before each Feature spec
before :each do
end

# Called after each Feature spec
after :each do
Capybara.reset_sessions!
end
end

gem 版本:

  • 最小测试 (4.7.5)
  • minitest- capybara (0.5.0)
  • minitest-focus (1.1.0)
  • 最小测试元数据 (0.4.0)
  • minitest-rails (0.9.2)
  • minitest-rails-capybara (0.10.0)
  • mobvious-rails (0.1.2)
  • 摩卡 (0.14.0)
  • 守卫 (2.2.4)
  • guard-minitest (2.1.2)
  • rb-fsevent (0.9.3)

最佳答案

解决方案:

我通过在我的 Guardfile 中添加“忽略”语句来解决它。对于我的 Rails 3 项目,它看起来像这样 (./Guardfile):

ignore([%r{^bin/*}, %r{^config/*}, %r{^db/*}, %r{^lib/*}, %r{^log/*}, %r{^public/*}, %r{^tmp/*}])

guard 'rspec', cmd: 'spring rspec', all_after_pass: false, all_on_start: false, focus_on_failed: true do
# Rails
watch(%r{^spec/.+_spec\.rb$})
...
end

这似乎是 guard/rspec/rails 的最佳实践。

守卫“忽略”信息:https://github.com/guard/guard/wiki/Guardfile-DSL---Configuring-Guard#ignore

我的问题

我在我的 mac os x 10.9 机器上遇到了非常相似的事情:

  • Spring (1.0.0)
  • rb-fsevent (0.9.3)
  • 咆哮 (1.0.3)
  • rspec-核心 (2.14.7)
  • rspec-expectations (2.14.4)
  • rspec 模拟 (2.14.4)
  • rspec (2.14.1)
  • guard-rspec (4.2.0)
  • 听 (2.4.0)
  • rspec-rails (2.14.0)
  • rails (3.2.15)

在启动 guard 运行我的 rspec 测试后,guard 进程在“空闲”时在一个核心上跳到 100% 负载,它保持这样的时间足以让我有资格称为“永远”。 :)

我试着跑卫

  • 强制轮询
  • 没有'watch'语句
  • 有 Spring
  • 没有 Spring

没有变化。

我的同事在同一个项目上使用 linux,所以他使用 rb-inotify 而不是 rb-fsevent。他在空转时没有负载(正如您对 mac os 的期望一样...)。

如上所述,我的解决方案是在我的 Guardfile 中添加“忽略”语句。

关于ruby-on-rails - Rails、Minitest 和 Guard - 为什么 rb-fsevent 占用了超过 100% 的 CPU?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20358502/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com