-
Notifications
You must be signed in to change notification settings - Fork 180
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
Performance Improvement Plan #1557
Comments
Thanks for the update! |
I think some sensible recognition of root modules in large monorepos would greatly help. You don't need to rescan every file (traces show you are) in a huge monorepo while I'm working on a single module. |
I used to have one window with many workspaces and then 1 or 2 windows with a much smaller number of workspaces (usually a couple root modules and the modules they depend on). |
We've just released With the fix, we should be back to 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 we're using this issue as a tracking issue. |
I just tested the changes in one of our older, large and monolithic terraform repos. The CPU usage and performance in the root of this workspace was terrible. |
I just installed v2.28.2023091812 |
I found #1328 (comment) which led me to this central issue for tracking all performance debugging. My current setup has A workaround is to enable this plugin only during terraform development and disable it right afterwards. Seems this is not fixed yet, please let me know if any more information is required and if I could help fix this permanently. |
As of v2.29.2, I'm still seeing ~10 GB of RAM usage by |
I'm seeing CPU usage of 200%+ and memory usage of over 9GB (I've seen up to 13Gb) on 2.29.3. I've tried disabling Enhanced Validation and that seems to help, but only a little. |
I found this thread while looking for "terraform high CPU usage" and just wanted to pitch in some help: I had the same problem and got notification from neovim (I know this is for vscode-terraform, but both use
And when I looked in the local Anyways, TL;DR, if you're experiencing performance issues, have a peek in your lsp logfile and |
I'll add that enabling |
My issue appears to be caused by an internal terraform modules repo we maintain. Many of our other repos use the internal modules repo, which results in every terraform directory in several of our large repos having a copy of that modules repo in its .terraform directory. Deleting as many of those .terraform directories as I can brings down the memory usage significantly- I was able to reduce usage from 10gb to 5.6gb by deleting around 8 directories. But that's only a temporary solution and requires constant upkeep. |
Coming here from hashicorp/terraform-ls#1272, I'd guess my issue is similar to the comment just above.
running latest stable ubuntu, terraform-ls version seems to be Machine has 16Gb ram and terraform-ls process results in system using swap and subsequently becoming completely unresponsive. |
Running into the same problem with internal modules we maintain. Working on one of those modules on an M3 Mac Pro, I'm seeing 700% CPU usage and 24GB of RAM. It's made using the VSCode plugin for terraform completely impossible. Folder structure is pretty small, just a subfolder for the module and the parent directory. This came out of nowhere, I've made changes to this module for months and everything has been fine. Today; it's completely unusable. The weird thing I'm noting is that my system is making millions of calls to terraform cloud, but we do NOT use it. Watching the calls via wireshark, there seems to be some sort of infinite recursion. It appears to be trying to sync to terraform cloud, failing, then trying again at an ever increasing rate. |
Hi @JBG-brad, I would love to get to the bottom of this, but so far we haven't been able to reproduce most of the shared cases of extreme resource usage. We try to get the schema for public modules from the public registry (https://registry.terraform.io/), but that should only happen once and the result is cached. It shouldn't happen for internal modules, and it definitely shouldn't happen in recursion. So I'm very curious to know what's going on. Maybe this could lead us to a new insight and improve performance for everyone. Can you share the full language server log output with me? Or, time permitting, could you join a call and show me the bug in action? If anyone else wants to share their log privately, or has an easily reproducible performance problem, please don't hesitate to contact me. |
my log file is more than 25MB repeating the same content. then I separated only a snippet of the [full log](Full log: https://gist.github.com/gullitmiranda/78d9bc59869c17a45846e99f9f999930), if it helps:
Full log: https://gist.github.com/gullitmiranda/78d9bc59869c17a45846e99f9f999930 |
I'd be happy to jump on a call and show you what's going on. I believe my email is in my profile. |
We've just released In VS Code, you can opt in to the extension preview: 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. Please open a new issue rather than replying here, as we're using this issue as a tracking issue. |
@dbanck i've open all the projects I have in my drive and seems to be behaving much better than ever before |
I've just installed it and restarted everything. Opened up some of my bigger projects and much better. Comfortably opened 4 projects 🫢 VS Code is just about snappy again, opening a new project takes a few seconds and does not completely choke up my machine 🚀 |
I can confirm that performance is massively improved using the pre-release version – thank you very much to all involved! Awesome work. |
Sadly, for bigger projects (100k lines), I feel the Terraform extension still tries way too hard and must be looking to parse every single file recursively - this is the only possibility I can think of. I'm still seeing the language server taking over 1 minute to return even after adding a single character to an existing string. I can sometimes see CPU spikes of 450%+ and a lot more memory than in this picture 😿 . |
@migueleliasweb Can you double check if you're using the preview version of the extension? Usually the path to |
Trying now. First impressions (30s of it) is that the "time to first interaction" feels faster and it seems to be using less memory. I'll post if I find anything. 🫡 I didn't know this thread was specifically abou the preview given the last stable was released 4 days ago. My bad. Edit: "onSaves" are now taking a few seconds instead of enough time to cook a bowl of rice 🎉 . I like this. |
The original issue was about performance, an update in preview was released 2 weeks ago |
We've shipped the re-architected language server in the 2.32.0 stable release last week. The language server will (still) start up much faster and use fewer resources, especially on larger workspaces. Please let us know if you experience any problems or regressions. |
Yep.. ours has 37.5k terraform files and unless you open a subfolder only in VSCode performance will be unusable... can't even save a file. |
Our terraform monorepo has only 1400 files (some of those are symlinked'ed repeats) over 110 folders, but I've have to give up on the VSCode extension two weeks ago. It took so long to save & format files (20-30 seconds) that I occasionally planned/applied on stale file content instead of the intended updated file, i.e. the extension was causing operational mistakes/bugs. I fear a lot of "nice to have" features have been added as the expense of performance of the core stuff - syntax highlighting & auto-formatting. When we can run |
Extension Version
v2.27.0
Problem Statement
We've been investigating performance for terraform-ls to develop a short term and a long term plan to address the issues that have been reported.
We know most of the issues reported surround the work we do in the background to provide features like intellisense, go to references, hover documentation, etc. When you open up the editor, we do a lot of work in the background to understand the code you're working on. We have an indexing process that finds all the Terraform files and modules in your current working directory, parses them, and builds an understanding of all the interdependencies and references inside. We hold this information inside an in-memory database, which we update as you change your files. If you open a directory with many hundreds of folders and files, this may consume more CPU and memory than we intend.
Proposal
In the short term we're working to add ways to measure and record the performance of terraform-ls in different situations so we can pinpoint the best path forward. We need a way to record the time it takes to perform various tasks in a manner that will give us the information we need while also respecting user privacy and not intruding on usage. We’ve started to instrument opt-in only performance tracing that is currently only used by the developers on the team.
We're also reaching out to users who have reported issues to get a closer look at how they are using VS Code to edit Terraform code. We've noticed that people edit their Terraform code using many different approaches. Some open single files, some open single folders, others open a directory containing many hundreds of modules and Terraform files. No individual approach is wrong or right, but each requires some consideration when developing a language server.
We've implemented several targeted improvements over the last several point releases based on our investigations: (1332 and 1258 ). We’ve also added a language status indicator in #1547 that approximates an indicator when the language server is ready for use so you can see that there are things happening in the background.
Most of the work we anticipate doing is optimizing these background processes. We plan to use the performance data we collect to inform places where we can either optimize or do less work entirely #1339. We are also planning to add a configuration setting #1341 so that users can adjust/tune the amount of workers handling these background jobs to suit their individual needs.
This is by no means all we intend to do, but it is a start. We are hoping these set of steps will inform us on the best approach for resolving these issues long term.
This issue will be pinned to the repo and updated with links to work being done to address this as they are planned and taken on.
Shipped
Stable extension 2.32.0
Stable extension 2.27.2
PreloadEmbeddedSchema
performance terraform-ls#1369Current Investigations
textDocument/didOpen
if content is the same as on disk terraform-ls#1375References
Help Wanted
Community Note
The text was updated successfully, but these errors were encountered: