Extension causes high cpu load

[Anthony-Ho]

hashicorp.terraform-unresponsive.cpuprofile.txt

• Issue Type: Performance
• Extension Name: terraform
• Extension Version: 2.8.2
• OS Version: Darwin x64 20.3.0
• VSCode version: 1.54.3

⚠️ Make sure to attach this file from your home-directory:
⚠️/var/folders/hb/xnhpm6ws28bgzf5lmzr0f4kr0000gn/T/hashicorp.terraform-unresponsive.cpuprofile.txt

Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

[radeksimko]

Thank you for the report, just looking into it.

[mattduguid]

Seeing 100% CPU/memory consumption after a recent terraform-ls upgrade to 2.10.1 in visual studio code running on ubuntu, workaround is to disable the extension for now, also get multiple copies of this error after a period of time "The Language Server: file:///<PATH_TO_MY_WORK> server crashed 5 times in the last 3 minutes. The server will not be restarted."

[radeksimko]

I'm still not sure what would cause the CPU load, but so many instances of LS running at the same time doesn't look right.

also get multiple copies of this error after a period of time "The Language Server: file:///<PATH_TO_MY_WORK> server crashed 5 times in the last 3 minutes. The server will not be restarted."

Can you take a look into the output pane, switch to terraform-ls and search for panic: and paste anything below (and including) that line which starts with panic?

[mattduguid]

Looks like there is a copy of terraform-ls for each one of my repos that contain terraform configuration which is 24 x ~150-200mb in size so that exhausts the memory fairly quickly as they appear to fire up in parallel when opening the workspace, I searched the output for "panic" but not found, however there are lots of repeats of this message,

2021/05/03 11:25:26 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:26 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:26 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:26 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:27 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:27 module_loader.go:118: no available capacity, retrying dispatch
2021/05/03 11:25:27 module_loader.go:118: no available capacity, retrying dispatch

another note is after about 20 mins of high cpu/memory it does eventually settle down but during the wait the machine is unusable, this definitely only started with the recent upgrade was working fine before that, can do a remote session if you want a closer look

[radeksimko]

@mattduguid Thank you for sharing these details and for your willingness to help debug this problem.

also get multiple copies of this error after a period of time "The Language Server: file:///<PATH_TO_MY_WORK> server crashed 5 times in the last 3 minutes. The server will not be restarted."

There was a bug in LS 0.16.0 where it would crash under certain conditions, but that bug is fixed in 0.16.1 (released on Friday 30th). Have you since tried upgrading to that version?

can do a remote session if you want a closer look

I would be more than happy to jump on a remote session with you. I can't see any contact details on your GitHub, but do let me know if you're still up for it - radek <at> hashicorp.com

I'm UK based, which could make scheduling a little bit tricky (assuming you're NZ based), but I hope we can still find a window?

no available capacity, retrying dispatch

This basically just means there are some background jobs (such as pulling schema or checking TF version) scheduled but prevented from running to avoid completely oversubscribing the CPU, but (obviously) these control mechanisms are only in effect within the process.

So each individual LS instance should be capped in terms of CPU usage, but I'm assuming the problem occurs when too many instances run in parallel. The LS/extension do not have native multi-workspace support yet, so it is possible that the extension will launch 1 LS instance for each workspace currently as a workaround. This would suggest you have ~24 workspaces (with TF code) opened/active in VS Code - is that right? If not then that sounds like a bug. If yes then that sounds like a +1 bump for this feature hashicorp/terraform-ls#482

[alexis-renard]

Hey, it seems that the issue came back on versions 2.[16,17].0. I have downgraded to 2.15.0 and it seems to be a bit better.

[vikas027]

Hey, it seems that the issue came back on versions 2.[16,17].0. I have downgraded to 2.15.0 and it seems to be a bit better.

Thanks, this has helped me as well. The extension was chewing 800% of my CPU on my Mac.

If someone else is too facing the same, this is what you have to do.

• Download the vsix from here
• go to the downloaded directory
• Run command code --install-extension HashiCorp.terraform-2.15.0.vsix

[jpogran]

All,

We recently released v2.180 of the extension, which changes terraform.codelens.referenceCount to be disabled by default. In certain scenarios the overhead of pre-calculating the number of references for each block in a document causes high CPU utilization. If you could update to the latest version and verify, we would sincerely appreciate it.

[vikas027]

hey @jpogran - I have tried the same and things are definitely looking better to me.

[radeksimko]

We have also just released language server 0.25.2 which patches a number of bugs, further reducing overhead (which could result higher CPU usage) in various scenarios, such as publishing diagnostics, refreshing code lens or telemetry.

With that in mind, I believe we have done all we could based on the data and knowledge available at this point, so I'm going to close this issue.

If someone still experiences high CPU usage after upgrading to the latest 2.18.0+ of the extension and 0.25.2 of LS, I would encourage you to file a new issue and attach details, such as log file, CPU profile and situation in which this occurs.

Language server gets updated automatically every 24hours or upon the next VS Code launch/restart, you can find the LS version near the top of the log under Output -> HashiCorp Terraform.

Thank you all!

[alexis-renard]

Looks better on the new versions on my side as well. Thanks for the fix ! (and thanks for our CPU loads as well)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.