search

graphql / vscode-graphql

MIGRATED: VSCode GraphQL extension (autocompletion, go-to definition, syntax highlighting)
https://marketplace.visualstudio.com/items?itemName=Prisma.vscode-graphql
MIT License
555 stars 71 forks source link

Persistent High CPU Usage #89

Closed oprica closed 5 years ago

oprica commented 6 years ago

Actual Behavior

Extension uses persistently high CPU in a VSCode project containing GraphQL configuration files with all tabs closed and all other extensions disabled.

Expected Behavior

Moderate to low CPU use.

Steps to Reproduce the Problem Or Description

  1. Create a blank new project
  2. Create a .graphqlconfig.yml within the project
  3. Reload VSCode

Specifications

Further Info

code --status

Version:          Code 1.28.2 (7f3ce96ff4729c91352ae6def877e59c561f4850, 2018-10-17T00:18:43.347Z)
OS Version:       Darwin x64 18.0.0
CPUs:             Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz (8 x 2500)
Memory (System):  16.00GB (2.48GB free)
Load (avg):       2, 2, 2
VM:               0%
Screen Reader:    no
Process Argv:
GPU Status:       2d_canvas:                    enabled
                  checker_imaging:              disabled_off
                  flash_3d:                     enabled
                  flash_stage3d:                enabled
                  flash_stage3d_baseline:       enabled
                  gpu_compositing:              enabled
                  multiple_raster_threads:      enabled_on
                  native_gpu_memory_buffers:    enabled
                  rasterization:                unavailable_software
                  video_decode:                 enabled
                  video_encode:                 enabled
                  webgl:                        enabled
                  webgl2:                       enabled
CPU %   Mem MB     PID  Process
    0       98   51019  code main
    0       49   51020     gpu-process
    0      197   51021     window (— test)
   26      115   51122       extensionHost
   76      147   51131         electron_node server.js
    0       49   51123       watcherService
    0       49   51126       searchService
    0       66   51132     shared-process
Workspace Stats:
|  Window (— test)
|    Folder (test): 1 files
|      File types: yml(1)
|      Conf files:
ps | grep 51131
vreid            51131  74.8  0.9  5128340 157452   ??  R     9:25am   2:39.04 /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper.app/Contents/MacOS/Code Helper /Users/vreid/.vscode/extensions/prisma.vscode-graphql-0.1.6/node_modules/vscode-languageclient/lib/utils/electronForkStart /Users/vreid/.vscode/extensions/prisma.vscode-graphql-0.1.6/out/server/server.js --node-ipc --clientProcessId=51122
aqwert commented 6 years ago

I get this also. Burns through CPU and therefore battery. Have just disabled extension to see if the issue resumes

Dieff commented 5 years ago

I can confirm that this is also an issue on Linux. Here is my system information:


OS Version:       Linux x64 4.19.2-arch1-1-ARCH
CPUs:             Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 800)
Memory (System):  15.55GB (9.74GB free)
Load (avg):       1, 1, 1
VM:               0%
Screen Reader:    no
Process Argv:
GPU Status:       2d_canvas:                    enabled
                  checker_imaging:              disabled_off
                  flash_3d:                     enabled
                  flash_stage3d:                enabled
                  flash_stage3d_baseline:       enabled
                  gpu_compositing:              enabled
                  multiple_raster_threads:      enabled_on
                  native_gpu_memory_buffers:    disabled_software
                  rasterization:                disabled_software
                  video_decode:                 unavailable_software
                  video_encode:                 unavailable_software
                  webgl:                        enabled
                  webgl2:                       enabled
CPU % Mem MB     PID  Process
    0    127    3537  code main
    0     32    3539     zygote
    0     96    3657       shared-process
    0    191    4604       window (datamodel.prisma - synapse - Visual Studio Code)
    0     96    4633         extensionHost
    0     48    4639         watcherService
    0     48    4659         searchService
    0     64    3577     gpu-process
Workspace Stats:
|  Window (datamodel.prisma - synapse - Visual Studio Code)
|    Folder (synapse): 162 files
|      File types: tsx(43) js(28) json(20) map(19) ts(14) png(11) graphql(3)
|                  example(2) production(2) env(2)
|      Conf files: package.json(3) tsconfig.json(2) tslint.json(1)
|                  settings.json(1) launch.json(1)
|      Launch Configs: node(2)```
darrenkeenn commented 5 years ago

Getting this too. CPU hitting 90% for a Code Helper instance as soon as I enable it.

lunelson commented 5 years ago

Got this too. It was clear to see, with multiple windows open, that only the project with .gql files in it was consistently at >65%. All windows down to 15% to 20% after disabling this extension.

vdiaz1130 commented 5 years ago

I confirmed this is happening. In VS Code under the extensions panel, I disabled all extensions. In Activity Monitor (OSX) I verified CPU usage seemed normal (i.e. no excessive usage or high fan speed). Enabling the GraphQL Prisma extension alone brought CPU usage to 85-90%. Disabling it brought it back down.

I did the same with other extensions (enable/disable, etc) and CPU usage remained normal. Finally I re-enabled all extensions (+50 installed). Fan speed and CPU increased. I disabled only GraphQL Prisma and CPU/Fan went back to normal.

I'm on OSX 10.12.6

GraphQL Ext Disabled: https://imgur.com/ZZLl6Qs GraphQL Ext Enabled: https://imgur.com/a/b2N49F4

BTW, I tried GraphQL for VSCode by Kumar Harsh and did not experience the same problems.

CalamityAdam commented 5 years ago

This is happening to me too. Oddly enough, this extension also seems to be using network data at a rate of about .1 MB / 5 seconds. The data is what originally made me investigate as suddenly VSCode was using dozens of MB per coding session

lunelson commented 5 years ago

Wait. Is this thing mining bitcoin? 🤣

vaunus commented 5 years ago

On further investigation it looks like this was introduced in 0.1.6. Installing 0.1.5 fixes the issue for me.

divyenduz commented 5 years ago

@vaunus : Thanks, I will looks for regressions between these two versions over the weekend. I am not sure what might be causing this though, the release was minor.

divyenduz commented 5 years ago

This is happening to me too. Oddly enough, this extension also seems to be using network data at a rate of about .1 MB / 5 seconds. The data is what originally made me investigate as suddenly VSCode was using dozens of MB per coding session

Can you investigate more about this network traffic (any more information would be helpful like url, how did you track it etc)? It should not be happening.

divyenduz commented 5 years ago

I am investigating this further today using the steps outlined in this document. Feel free to help me out in it by running these steps on your machine (in a classic manner, my machine has no CPU usage issues - trying with bigger and various projects now) . We can also pair on this, if any of you also happen to be available :)

aflansburg commented 5 years ago

Same issue here regarding CPU usage. Attaching the profile collected / recorded in vscode on the extension running with it running and screenshot.

CPU-20190122T040407.032Z.cpuprofile.txt

screen shot 2019-01-21 at 9 57 30 pm
aflansburg commented 5 years ago

Read that many times issues like this can be caused by large number of files to load so MS suggests bundling in order to reduce and minify. Could be the issue? https://github.com/Microsoft/vscode-extension-samples/tree/master/webpack-sample

divyenduz commented 5 years ago

@oprica, @aqwert, @Dieff, @celticdarren, @lunelson, @vdiaz1130, @CalamityAdam Can any of you share a small sample project where this happens?

I can confirm this bug (based on more information I got from other sources) + the bug also causes network spikes as suggested by @CalamityAdam but I am unable to reproduce it locally.

I tried various combinations of project config but unable to see CPU spikes, can you share a minimal reproduction repository of a project which when opened with VSCode + this extension causes the issues? Thanks.

P.S. The current reproduction by @oprica doesn't even trigger the extension as it does not talk about any .graphql or .ts files :)

vaunus commented 5 years ago

@divyenduz I've had a bit of a look into this today and I've found the source of the problem however I don't have any experience with writing VSCode extensions so unsure how to fix it.

See https://github.com/vaunus/prisma-vscode-high-cpu-sample which causes this issue for me even with just an empty .graphqlconfig.yml file as the only file in the project. It only appears to cause high CPU when VSCode first opens with that file already created or if you reload the window. If I create the file after VSCode is open already it doesn't cause high CPU until I close and reopen VSCode or perform a window reload. If I then delete that file the 100% CPU issue resolves immediately and I see output: 

Caught the error when there is no GraphQL config file: Error: Request initialize failed with message: ".graphqlconfig" file is not available in the provided config directory: /Users/vreid/Documents/Workspaces/Node/prisma-vscode-high-cpu-sample
Please check the config directory.

I saw you added CustomInitializationFailedHandler.ts in a recent commit which is responsible for that error output above however it looks like this error handler is also actually masking the error causing the high CPU. If I add console.log(error); to line 12 of that file I am seeing this error logged out nearly 1000 times a second over and over again which must surely be the cause of the high CPU. The error itself is below but given my limited experience, I've been unable to track down the source of it:

Error: Request initialize failed with message: Cannot read property 'extensions' of undefined
CustomInitializationFailedHandler.js:6
    at new ResponseError (/Users/vreid/Documents/Workspaces/Node/vscode-graphql/node_modules/vscode-jsonrpc/lib/messages.js:46:28)
    at handleResponse (/Users/vreid/Documents/Workspaces/Node/vscode-graphql/node_modules/vscode-jsonrpc/lib/main.js:430:48)
    at processMessageQueue (/Users/vreid/Documents/Workspaces/Node/vscode-graphql/node_modules/vscode-jsonrpc/lib/main.js:258:17)
    at Immediate.<anonymous> (/Users/vreid/Documents/Workspaces/Node/vscode-graphql/node_modules/vscode-jsonrpc/lib/main.js:242:13)
    at runCallback (timers.js:696:18)
    at tryOnImmediate (timers.js:667:5)
    at processImmediate (timers.js:649:5)

Hope this helps you figure it out! If you still can't reproduce this on your side I'm happy to pull in any commits for testing on my side. Just let me know. 😄

P.s. I've switched to @vaunus as oprica is my other account that I accidentally posted this under originally...

divyenduz commented 5 years ago

@vaunus : Thanks, this is amazing, exactly the kind of repro I was looking at 🙏

I did attempt an empty GraphQL file but never got to CPU load, maybe there is a flag or something. I will attempt a fix for this asap!

divyenduz commented 5 years ago

@vaunus : Thanks, I was able to reproduce this with the reproduction and the fix is available, some minor issues on my MS account but I should be able to publish a fix shortly, I will close this issue once the fix is available in 0.1.7. I missed it in the original reproduction because I tested for these cases:

  1. Missing .graphqlconfig
  2. Valid .graphqlconfig

What I however did not check for was an invalid .graphqlconfig like an empty file (not sure if that is invalid by GraphQL config spec though).

The original API of CustomInitializationFailedHandler was supposed to handle the missing file case and revert to default error handling for all errors but this is not how VSCode initializationFailedHandler API works.

In implementation, once you start using the initializationFailedHandler, it is a separate codepath and if I return true from the custom handler, it will just attempt a reinitialization infinitely with no limit/backoff period as opposed to the default behavior where it crashed after 5 failed attempts on reinitialization. I will raise an issue on the original repository because this is an easy place to be wrong at :)

Thanks everyone involved in reporting this issue. Thanks @vaunus for providing the reproduction.

divyenduz commented 5 years ago

@vaunus : 0.1.7 is available that fixes this issue, please validate if the issue is indeed fixed and close this issue. Thanks again :)

vdiaz1130 commented 5 years ago

After reinstalling the plugin, I can verify that the high CPU issue is no longer happening. Thanks!

vaunus commented 5 years ago

Looking good my side as well. Thanks @divyenduz!