plugin is eating CPU and RAM under Linux x86_64

[vromanocarepay]

Versions

Extension

[2.26.1](https://github.com/hashicorp/vscode-terraform/compare/v2.26.0...v2.26.1) (2023-05-11)

VS Code

Version: 1.78.2
Commit: b3e4e68a0bc097f0ae7907b217c1119af9e03435
Date: 2023-05-10T14:47:05.613Z
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Linux x64 6.3.2-zen1-1-zen
Sandboxed: Yes

Operating System

Linux Feynman 6.3.2-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Thu, 11 May 2023 16:40:19 +0000 x86_64 GNU/Linux

Terraform Version

1.0.2

Steps To Reproduce

1. Startup vscode
2. Open a terraform repo directory with terraform code
3. Wait a few seconds.
4. Run htop or top or ps or any other OS diagnostics

Expected Behavior

CPU and RAM usage has a slight yet negligible increase.

Actual Behavior

CPU gets close to 100% on all cores.
RAM usage goes above 12 GB (I have 24 luckily)
System fans spin noisily
The process(es) called .vscode/extensions/hashicorp.terraform-2.26.1-linux-x64/bin/terraform-ls serve eat a lot of resources.

Additional context

Closing the editor panel with terraform code is not enough.
Closing the editor window (I have other ones but woth no terraform code) is enough to bring the system to normal.
I have tried also the pre-release version with no luck.

[libfitz]

I have the same issue on macOS.

---

Extension

2.26.1, also tried rolling back to 2.25.4, but no improvement.

VS Code

Version: 1.78.2
Commit: b3e4e68a0bc097f0ae7907b217c1119af9e03435
Date: 2023-05-10T14:44:45.204Z (2 wks ago)
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Darwin x64 21.6.0
Sandboxed: No

Operating System

macOS 12.6.6

Terraform Version

1.4.6

[libfitz]

I must add that using an external language server works much better.

$ ~/.vscode/extensions/hashicorp.terraform-2.26.1-darwin-x64/bin/terraform-ls version
0.31.2
platform: darwin/amd64
go: go1.19.9
compiler: gc

$ sha256sum ~/.vscode/extensions/hashicorp.terraform-2.26.1-darwin-x64/bin/terraform-ls
93c891074fcde4cda7437df5d43605ac5a6140d62e1e210cc72dd0c66f68ca46  /Users/username/.vscode/extensions/hashicorp.terraform-2.26.1-darwin-x64/bin/terraform-ls

$ /usr/local/bin/terraform-ls version
0.31.2+Homebrew
platform: darwin/amd64
go: go1.20.4
compiler: gc

$ sha256sum $(readlink -fn /usr/local/bin/terraform-ls)
a036370b6dbe80e352142e6cf12e60314700539b8557ba5119937a48fbbe77f0  /usr/local/Cellar/terraform-ls/0.31.2/bin/terraform-ls

[radeksimko]

We intend to further investigate the performance issues, although the realistic expectation to set here is that amount of memory and CPU will generally always be proportional to the size of the workspace being processed, number of providers used etc., not static.

In the interest of transparency (and hope of building some empathy on all sides), I will say that we have not yet invested much effort into optimising for the higher end of workspace sizes. Identifying the different scales (esp. the higher end) and measuring how different parts of the language server behave under those scales is what we plan to do as part of hashicorp/terraform-ls#1056 We will also reach out to you all as part of that work.

@libfitz the most likely reason it may look that the community-compiled server available from Homebrew works "better" is because it does not provide the same functionality the official packages do through embedding provider schemas and baking in API keys for module source completion in the Terraform Registry. If you have none or only few root modules (those which have been initialised via terraform init) in the workspace tree, then this results in less resource usage as the configuration cannot be decoded fully without the providers, and the completion/hover/etc. provided will be significantly more limited as a result.

The only workaround for the moment is to avoid opening large workspaces and rather open individual folders nested within the tree, or at least smaller part of the tree. I appreciate this may not be the answer you're looking for, but I hope the context is helpful.

[jpogran]

We know this has been a frustrating experience and appreciate your understanding while we gathered feedback and examples to diagnose this issue. We've created #1557 as a central place to see updates on what we are doing to address performance issues in terraform-ls in both the short and long term and pinned it to the repo. We'll be adding more detail there as we implement fixes. As we work on this we'll be recording the content and then closing the individual issues so that everyone has one place to look at instead of searching for individual tickets for updates.

[jpogran]

We've released 2.27.2 which contains two fixes (hashicorp/terraform-ls#1369, hashicorp/terraform-ls#1372) in our continuing efforts to address this issue.

With the fix, we should be back to terraform-ls v0.29.2 levels of CPU usage while maintaining the memory improvements of v0.29.3.

If you have the time, please give it a try and let us know how it works for you. Please open a new issue rather than replying here, as this issue has gotten so many replies with different experiences it is hard to process.

I am going to close this as we're using #1557 as a central tracking issue, so subscribe to that to see continued updates.

[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.