Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High CPU #54

Open
OZZlE opened this issue Nov 15, 2019 · 6 comments
Open

High CPU #54

OZZlE opened this issue Nov 15, 2019 · 6 comments

Comments

@OZZlE
Copy link

OZZlE commented Nov 15, 2019

I am using this inside Vagrant host Linux, client Mac. It seems like after a while it starts eating more and more CPU especially when I have had my Mac in sleep I need to like restart the box and start watching again or my computer is like unusable.

On my Mac I see it's vagrant VM using most CPU and when I run top inside the VM it says node at the top, and this is the only nodejs job I have running..

Could something be improved perhaps= :)

From top inside Vagrant:

  PID   USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                                 
  21537 vagrant   20   0 1075340 282260  30812 S 44.2  3.5  10:26.63 node         
@statianzo
Copy link
Owner

What does top look like after a similar amount of time using webpack without this plugin?

@OZZlE
Copy link
Author

OZZlE commented Nov 16, 2019

What does top look like after a similar amount of time using webpack without this plugin?

We only use Node to build our React client side app. So building without watching Node will just quit after the build process is done.. so not sure how to answer that..

@OZZlE
Copy link
Author

OZZlE commented Nov 18, 2019

We're using version 1.2.0 of this plugin, I tried to update to the latest now but then watch doesn't work anymore only getting:

.../node_modules/webpack/bin/webpack.js:348
            throw err;
            ^

TypeError: Cannot read property 'compilation' of undefined
    at LiveReloadPlugin.apply (.../node_modules/webpack-livereload-plugin/index.js:133:18)
    at Compiler.apply (.../node_modules/tapable/lib/Tapable.js:375:16)
    at webpack (.../node_modules/webpack/lib/webpack.js:33:19)
    at processOptions (.../node_modules/webpack/bin/webpack.js:335:15)
    at .../node_modules/webpack/bin/webpack.js:397:2
    at Object.Yargs.self.parse (.../node_modules/webpack/node_modules/yargs/yargs.js:533:18)
    at Object.<anonymous> (.../node_modules/webpack/bin/webpack.js:152:7)

We're using webpack version 3.12.0

@statianzo
Copy link
Owner

We only use Node to build our React client side app. So building without watching Node will just quit after the build process is done.. so not sure how to answer that..

If you remove this plugin and run webpack --watch for the same amount of time (with manual refreshing), does your CPU usage grow? If so, that's a webpack issue.

If you're using Vagant, historically shared filesystems are slow. That could be a contributing factor.

If the CPU stays at 40%, that also makes me suspect that webpack is polling on the shared filesystem instead of using kernel inotify events. If that's the case, reducing the number of files checked may help reduce load. See webpack's watchOptions.ignored. Consider disabling watch of node_modules.

We're using version 1.2.0 of this plugin, I tried to update to the latest now but then watch doesn't work anymore only getting:

Only version 1.x will work with webpack 3.

@OZZlE
Copy link
Author

OZZlE commented Jan 17, 2020

I'm now running this watcher locally instead of inside vagrant which seems to work better (albeit chrome block live reloading then)

But it seems to use a lot of memory still, I am not sure how nice it is from me to complain on the previous major version of this module though :P although it's not super easy to update webpack version always... I though I would just add this information anyway in case someone will have time to fix it :)

After changing git branch node crashed with the following report:

    <--- Last few GCs --->
    ca[61332:0x1026a0000] 22280346 ms: Mark-sweep 2046.3 (2060.2) -> 2045.0 (2061.7) MB, 2319.0 / 0.0 ms  (+ 0.0 ms in 66 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2342 ms) (average mu = 0.100, current mu = 0.010) alloca[61332:0x1026a0000] 22283655 ms: Mark-sweep 2046.2 (2061.7) -> 2045.7 (2060.2) MB, 3192.3 / 0.0 ms  (+ 106.7 ms in 20 steps since start of marking, biggest step 9.3 ms, walltime since start of marking 3309 ms) (average mu = 0.042, current mu = 0.003) fina

    <--- JS stacktrace --->

    ==== JS stack trace =========================================

        0: ExitFrame [pc: 0x100ea9f02]
        1: StubFrame [pc: 0x100eaae53]
    Security context: 0x1a360159a2f1 <JSObject>
        2: formatError(aka formatError) [0x1a368c6b83f9] [[the-PROJECT_ROOT_folder]/node_modules/webpack/lib/Stats.js:~186] [pc=0x3779d3281e0](this=0x1a366c6004d1 <undefined>,0x1a363963e951 <Error map = 0x1a369f1c87a9>)
        3: arguments adaptor frame: 3->1
        4: map [0x1a360158c321...

    FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

    Writing Node.js report to file: report.20200117.082026.61332.0.001.json
    Node.js report completed
     1: 0x100075bd5 node::Abort() [~/.nvm/versions/node/v12.4.0/bin//node]
     2: 0x100076316 node::errors::TryCatchScope::~TryCatchScope() [~/.nvm/versions/node/v12.4.0/bin//node]
     3: 0x1001697d7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [~/.nvm/versions/node/v12.4.0/bin//node]
     4: 0x10016976c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [~/.nvm/versions/node/v12.4.0/bin//node]
     5: 0x1005480d5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [~/.nvm/versions/node/v12.4.0/bin//node]
     6: 0x1005491c3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [~/.nvm/versions/node/v12.4.0/bin//node]
     7: 0x100546bc3 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [~/.nvm/versions/node/v12.4.0/bin//node]
     8: 0x10054487f v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [~/.nvm/versions/node/v12.4.0/bin//node]
     9: 0x10054f365 v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [~/.nvm/versions/node/v12.4.0/bin//node]
    10: 0x10054f3df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [~/.nvm/versions/node/v12.4.0/bin//node]
    11: 0x10051e10f v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [~/.nvm/versions/node/v12.4.0/bin//node]
    12: 0x1007cecf4 v8::internal::Runtime_AllocateInNewSpace(int, unsigned long*, v8::internal::Isolate*) [~/.nvm/versions/node/v12.4.0/bin//node]
    13: 0x100ea9f02 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [~/.nvm/versions/node/v12.4.0/bin//node]

@statianzo
Copy link
Owner

Thanks for the update @OZZlE.

This looks to stem from a call Stats.toJson(), an expensive operation for bigger projects when no filtering options are passed. That's where formatError is located.

https://github.com/webpack/webpack/blob/v3.12.0/lib/Stats.js#L186

As far as I can see, webpack-livereload-plugin doesn't call it. If you can find a call stack that causes it to get invoked from this plugin, then let's find a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants