terraform-ls is using 100% CPU

[janekolszak]

Language Server Version

0.32.4

Terraform Version

1.6.5

Client Version

VSC

Behavior

top says terraform-ls uses 100% CPU. This is true for the last couple months.

Steps to Reproduce

Open VSC. No terraform file is open.

Terraform Configuration

No response

Project Structure

No response

Gist

No response

References

No response

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[dbanck]

Hi @janekolszak,

Thanks for taking the time to report this. We're always curious to hear about performance issues in different environments.

Can you give us more information about your project structure? Are you opening a large workspace in VS Code?
Does your project use symlinks?

When you open a workspace in VS Code, `terraform-ls' CPU usage usually spikes to 100% for a few seconds as we index the files to build an internal representation of the project structure. I assume you're seeing high CPU usage for a longer period of time?

[samuelb]

I discovered the same with my NeoVIM setup on a M1 Macbook. Whenever the LSP-server is in use, the CPU utilization of terraform-ls is high and responses comes with great delay.

The Terraform folder I'm working in has 54 files and 3600 lines of terraform code. On smaller projects, I cannot observe this issue.

With version 0.31.5 it works fine, but not with 0.32.0 or 0.32.5.

[janekolszak]

Workspace contains couple big projects in golang and infrastructure setup using around 10 terraform repos, each with around 10 files. Ubuntu 22.04.3

CPU is 100% for all the time VSC is open.

[notorand-it]

I confirm this is happening to me too quite often, but not always.
I currently have just one vscode window open on a (relatively) small project and a couple of browser windows.
After terraform init the directory weights about 766 MiB.
The CPU usage stays high for more than 15 minutes and makes my PC barely usable.
I can "bring it down" with a simple (bash) command like this:

{ while true; do killall -9 terraform-ls &> /dev/null; sleep 1m; done } &

But this is clearly not even a workaround: it's a stinky hack.

My environment is like this:

System: ArchLinux

Kernel Version : 6.6.8.zen1-1
Plasma Version : 5.27.10-1
KDE Version : 23.08.4-1
Frameworks Version : 5.113.0-1
Qt5 Version : 5.15.11+kde+r12-1
Qt6 Version : 6.6.1-3
Wayland Version : 1.22.0-1
XOrg/Wayland Version : 23.2.3-1
Mesa Version : 1:23.3.2-1
LibVA Version : 2.20.0-1
VDPAU Version : 1.5-2

terraform-ls

0.32.4
platform: linux/amd64
go: go1.21.4
compiler: gc

terraform

Terraform v1.6.6
on linux_amd64

VSCode

Version: 1.85.1
Commit: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
Date: 2023-12-13T09:47:11.635Z
Electron: 25.9.7
ElectronBuildId: 25551756
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.6.8-zen1-1-zen

VSCode Extension

HashiCorp Terraform v2.29.1

[notorand-it]

On Linux a solution could be to spawn the language server binary and immediately change its prios with:

• nice level: 19
• ionice class: idle (3)

This would mitigate the problem, while not really solving it.
For other OSes I have no idea.

[rd-michel]

+1

terraform-ls using 700% cpu while working on a big repository with multiple terraform projects/directories.

[ayofishr]

+1

Can confirm this is happening on an M2 Macbook Pro using Neovim 0.9.5.
Had to disable the plugin, because it was stressing my CPU out.

The issue started appearing less than a couple of weeks ago.

Working on very small projects with very small files.

The version of terraform installed on my system currently is 1.7.3

[dbanck]

@ayofishr small projects with small files sound like an ideal way to reproduce the issue. Would it be possible for you to share that with us?

You may also send it privately via email to daniel.banck<at>hashicorp.com if you wish.

[ayofishr]

@dbanck Hello Daniel ! Sorry for the late reply.

I've had a look at the lsp logs under ~/.local/state/nvim/lsp.log and this the message I get (hundreds of them at a time)

[ERROR][2024-03-13 10:10:01] .../vim/lsp/rpc.lua:734 "rpc" "/Users/ayofishr/.local/share/nvim/mason/bin/terraform-ls" "stderr" 

{
  "start": {
    "line": 1,
    "character": 785
  },
  "end": {
    "line": 1,
    "character": 786
  },
  "severity": 1,
  "source": "Terraform",
  "message": "Invalid character: This character is not used within the language."
}

My lsp config looks like this

lspconfig["terraformls"].setup({
	capabilities = capabilities,
	on_attach = on_attach,
})

This happens even in the smallest possible projects (ie: a single main.tf file)

[dbanck]

@ayofishr What's the content of line 1? Can you share the first few lines of your configuration?

The message indicates that the HCL parser encountered an unsupported token

[ayofishr]

@dbanck Nevermind. I manually deleted terraform-ls and reinstalled it with mason and now everything's fine.
I don't why it behaved the way it did though. (For context, CPU usage would spike even on empty files)
Thank you for your help 😄 (and sorry for the late reply)

[ayofishr]

@dbanck

Quick Update. The issue started appearing again yesterday.

After bisecting my neovim config, I was able to find the source of the issue.

The CPU spike and the errors logged above were caused by tflint, which displays diagnostics information in the current buffer. These strings contain unsupported characters (such as icons and glyphs).

After disabling the plugin, everything started working as expected.

Hope this helps people who encounter this issue in the future.

Thanks again for the wonderful work on this LS 😄

[dbanck]

@ayofishr Interesting discovery. Thank you for sharing this.

[github-actions]

Marking this issue as stale due to inactivity over the last 30 days. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

Thank you for understanding.

[psibi]

I can reproduce the same with the latest terraform-ls:

❯ terraform-ls --version
0.33.1

I'm editing a 1000 lines terraform file and the issue is reproducible instantaneously in that project. I enabled logs and found that receiving response for textDocument/documentLink is taking more than ~ 13 second which might be the culprit. From my logs:

❯ rg "textDocument/documentLink" lsp_log.txt
549:[Trace - 02:52:37 PM] Sending request 'textDocument/documentLink - (1718)'.
707:[Trace - 02:52:37 PM] Sending request 'textDocument/documentLink - (1726)'.
791:[Trace - 02:52:38 PM] Sending request 'textDocument/documentLink - (1729)'.
950:[Trace - 02:52:38 PM] Sending request 'textDocument/documentLink - (1733)'.
999:[Trace - 02:52:40 PM] Sending request 'textDocument/documentLink - (1736)'.
1069:[Trace - 02:52:46 PM] Sending request 'textDocument/documentLink - (1740)'.
1103:[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1718)' in 13707ms.
1111:[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1726)' in 13235ms.
1122:[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1733)' in 12637ms.
1130:[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1729)' in 12658ms.
2839:[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1740)' in 4827ms.
41266:[Trace - 02:52:51 PM] Received response 'textDocument/documentLink - (1736)' in 10653ms.
41410:[Trace - 02:52:51 PM] Sending request 'textDocument/documentLink - (1742)'.
41422:[Trace - 02:52:51 PM] Received response 'textDocument/documentLink - (1742)' in 10ms.
41447:[Trace - 02:53:09 PM] Sending request 'textDocument/documentLink - (1744)'.
41459:[Trace - 02:53:09 PM] Received response 'textDocument/documentLink - (1744)' in 22ms.
41500:[Trace - 02:53:10 PM] Sending request 'textDocument/documentLink - (1747)'.
41528:[Trace - 02:53:10 PM] Received response 'textDocument/documentLink - (1747)' in 16ms.

Inspecting that specific log, the result was empty:

[Trace - 02:52:50 PM] Received response 'textDocument/documentLink - (1718)' in 13707ms.
Result: []

Unfortunately I can't share my code, but would be able to help test out any PR's for fixing this bug.

[ckreiling]

+1

Experiencing the exact same things in Neovim, particularly a ton of events are handled quite slowly on every keystroke.

Project consists of 30 files, using about 5 providers and referencing >10 modules from GitHub.

CPU usage spikes beyond 150%, immediately upon pressing a key after entering insert mode. Outside of insert mode CPU usage is low.

Deleting tflint from the LSPs running alongside terraform-ls did not resolve the issue for me.

[dbanck]

We've just released v0.34.0-alpha20240611, which ships with a re-architecture for improved performance and resource usage (terraform-ls#1667). The language server will now start up much faster and use fewer resources, especially on larger workspaces.

If you have the time, please give it a try and let us know how it works for you. We have tested this with workspaces of different sizes, but still expect some bugs due to the wide variety of configurations. Your feedback is greatly appreciated.

[psibi]

Thanks! Is there a binary (preferably static) available somewhere that I can test with or do I need to compile it ?

[dbanck]

@psibi Oh sorry, I forgot to mention this. You can get the binary from https://releases.hashicorp.com/terraform-ls/0.34.0-alpha20240611/

[psibi]

Thanks, this definitely has improved the situation. I haven't been able to reproduce the bug which was trivially reproducible in the older version of terraform-ls.

I will keep an eye on my CPU consumption and update this issue if I'm able to see with the latest alpha version.

[dbanck]

We've shipped the re-architected language server as part of the 0.34.0 stable release last week. The language server will start up much faster and use fewer resources, especially on larger workspaces.

I would like to close this issue for now. Please let us know if you experience any problems or regressions.

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