Pegging CPU core on Apple M1 processor

[henryaj]

Running Ruby 2.7.1 and Spring 2.1.0 (in a Rails 6.0.3.2 app) on an M1 MacBook Air under Rosetta (running the whole shell in x86 mode) I'm seeing spring pegging a whole CPU core (CPU usage of 99%).

Curious to know if others are seeing the same, and what the best way to debug this is!

[andersoncardoso]

I'm also seeing this happen on an intel mac on Big Sur.
I used to work on this same project and same machine and never had this issue.
After upgrading the OS, whenever I start a process (even an idle rails console) the cpu stays at 100% and the fan goes at top speed.
If I run without spring (DISABLE_SPRING=1) then the problem disapears.

[henryaj]

Interestingly I'm also seeing this happen with guard – maybe something up with the way these two things watch the filesystem for changes?

[bdibon]

Same here, I'm on macOS Big Sur v11.1, using rails v6.1.0. Whenever I run rails test a ruby process uses ~100% of my CPU, as you can see on the ps aux output below. The process comes back whenever I kill it with the Activity Monitor GUI, the only way to stop it is to exit the terminal session.

USER               PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
bdibon            3370 100.0  1.2  4461052 104256   ??  Rs    1:22PM   0:07.83 ruby -I /Users/bdibon/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/spring-2.1.1/lib -e require 'spring/application/boot'

PS: I have an Intel Core i5, the CPU is probably irrelevant for this issue.

[andersoncardoso]

@bdibon have you tried running spring stop on the terminal? it might prevent you from having to exit the session.

[bdibon]

@andersoncardoso It works ! Nice improvement to my current flow, I guess it opens the door to some rails t && spring stop aliasing. Thank you.

Edit: you might prefer to use rails t; spring stop, the first command will only reward you if your tests are green lol.

[andersoncardoso]

Adding some findings here:
This is related to the spring-watcher-listen gem (and since this is also happening to guard, then the issue must come from listen).
I tried adding several folder patterns to listener.ignore in hope that it was because of node_modules or public/packs (from webpack), but nothing worked.
So I found a workaround by using polling mode. For that, you either remove the spring-watcher-listen gem or you can add the line below to your config/spring.rb:

Spring.watch_method = :polling 

in my case I added a check for an env var, so my co-workers can still use the evented file watcher while I toggle off.

Notice this will still keep you cpu at around 25 - 30% even without any rails process (server, console, etc) running, just with spring on the background. But it's better than 100% and the cooler fan going crazy.

I hope this helps

[jeremy]

Could you please open an issue with the Listen gem to troubleshoot? Thank you for reporting!

[raldred]

Anyone coming here, this is a bug with the listen gem not supporting BigSur the fix for us was to update the listen gem to >3.3.0.
In a standard rails app of various versions it's pinned to '~> 3.0.5', '<3.2'

We updated our Gemfiles to gem 'listen', '>=3.0.5', '<4.0'
to get the update which was fixed in listen 3.3.0

[perryraskin]

I'm on an M1 MacBook Pro and recently began using the new Shopify CLI. Ruby is constantly using 100% CPU even when I'm not running the local theme server, and causing the fan to turn on (which has never happened before, and I've had this laptop for 6+ months).

Is there something I can do or does Shopify need to push some sort of fix?

Update: I originally installed shopify-cli via Homebrew. I uninstalled it and installed it via gem instead. So far I'm no longer experiencing that heating & fan issue. Hopefully it stays this way.

[eatingsnacks]

@perryraskin Thanks I am seeing this with Shopify CLI as well. I will try your fix. I don't see any mention of it in their issues surprisingly..

[thadeu]

Anyone coming here, this is a bug with the listen gem not supporting BigSur the fix for us was to update the listen gem to >3.3.0. In a standard rails app of various versions it's pinned to '~> 3.0.5', '<3.2'

We updated our Gemfiles to gem 'listen', '>=3.0.5', '<4.0' to get the update which was fixed in listen 3.3.0

Update listen gem resolved for me. (macbook m1 2020)
Thanks @raldred