Closed slayer closed 3 years ago
I'm facing the same issue, though without delayed job but with spring. After some investigation, I've found that in high-cpu times process has this backtrace:
I've found that Change#invalidate
is extensively called with ./tmp/cache
and ./tmp/uploads
which is used to store uploads in tests. It also noticeable that it starts using cpu after test suite finished, as it clears ./tmp/uploads
after tests.
By default rails adds ./tmp/restart.txt
to watchlist, I've tried removing it but got same result.
I've also had 150% cpu usage while in the pry rails console in rails 5.1.4 with listen 3.1.5 under ruby 2.4.2 on macOS 10.13.3.
After killing all listen threads with Thread.list[1..-1].each(&:kill)
CPU usage went back to normal.
I didn't take a backtrace from the threads, but will do so if I encounter the issue again.
This is killing me as well. A page reload in development takes around 60 seconds.
Here's a flamegraph of a request. 85% of the time spent in listen:
I removed gem 'listen'
from my gemfile, ran bundle lock --update=listen
, and the issue went away.
Please let us know if this problem persists under v3.3
(currently available in v3.3.0.pre.2
).
Hi
I have a problem with
listen
gem withdelayed_job
- it eats 100% of cpu corestrace log:
removing
listen
gem with commenting outEventedFileUpdateChecker
solves the problemTroubleshooting: 1.
There is no effect in output on
touch foo
no effect on
touch foo2
problem repreduced in host system (linux) and in the docker container ruby: ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
Thanks