x/tools/gopls: high CPU & memory for minutes in "Saving foo.go: Getting code actions from "Go" ..." #57707
Comments
gopherbot
added
Tools
|
Similar experience. Saving whilst not having a go.mod file present grinds to crawl. |
|
Well, I have go.mod files. |
|
Gopls is generally resource hungry on large (or even medium large) workspaces. Furthermore, it is sensitive to which directory you open. Couple questions:
From that profile, it looks like the typical parsing / typechecking / gc slowness, so I'm not sure there's a solution for you with the current execution model. The issue @renthraysk cited is a known problem related to scanning files, but that doesn't seem to be the cause of what you're experiencing. @adonovan and I are working to move gopls off of its monolithic build model, which should finally allow us to solve this category of problem. |
|
FWIW, in my experience, this can occur when gopls gets into a bad state. It is responsive (enough) working on a project, it gets unhappy, and then saving fails until you kill and restart it. For others experiencing this, you can get past it in a pinch by using the VSCode command palette to do "Save without formatting". And then restarting. :/ |
|
Hmm, that's... unfortunate. The likely cause of that is that gopls has loaded a bunch of packages (intermediate test variants) for e.g. a references request, and holds on to them until a restart. This particular behavior will be fixed in the next gopls release. |
adonovan
added
the
gopls/performance
|
I had something similar happen last weekend... Gopls was going bonkers taking over cpu on my box while debugging from vscode. I couldn't get back control of the UI and I made the mistake of hard rebooting in the middle (just trying to get my cpu back) which unfortunately bricked my harddrive and OS. I'd had problems with this pet project in the past using gopls. I think it may have had something to do with having a largish bound resource file (but not unreasonable) but that's only a wild guess because I can't repro due to bricking. I should have waited for 1.20 because I was hoping that might help with this.... But I was eager to do a few things... sigh I accepted the risks of using the latest gopls I guess and knew this was a possibility but up to this point have never seen go involved in anything like this before. It could be that my SSD was on the verge of breaking anyhow and the extra activity pushed it over. One thing I did notice before it crashed... swap had been triggered and cpu was aggressively trying to swap. I also noticed that gopls seems to leave a bunch of stale folders in /tmp and there were many many in there. Up to this point I had not put effort into managing /tmp. |
|
Oof, sorry about that @joel-rieke It sounds like there may be something we don't understand going on here, but we are in the process of making major changes to the way gopls executes (https://go.dev/issue/57987), and my hope is that it makes all of these problems go away. |
No worries, this doesn't change my love of programming in go believe it or not. I'll find my way back. And yes, hopefully the new gopls helps! :) |
What version of Go are you using (
go version)?Go 1.19.4
gopls 0.11.0
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?darwin/arm64 Visual Studio Code => ssh to linux/amd64
What did you do?
I'm trying to become a Visual Studio Code + gopls user, trying to break my emacs habit. I use Visual Studio Code on a Mac over SSH to a Linux server, where gopls/etc runs remotely.
A good fraction of the time when I save in VS Code, I see:
For minutes.
Meanwhile, gopls is using 4-8 GB or more of memory and using tons of CPU.
perf topsays:What did you expect to see?
Faster, I guess.
What did you see instead?
Slower than it seems it should be.
Is this a bug?
I don't know how to go about debugging gopls.
The text was updated successfully, but these errors were encountered: