Skip to content
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

x/tools/gopls: high CPU & memory for minutes in "Saving foo.go: Getting code actions from "Go" ..." #57707

Open
bradfitz opened this issue Jan 9, 2023 · 8 comments
Assignees
Labels
gopls/performance Issues related to gopls performance (CPU, memory, etc). gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Jan 9, 2023

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:

Screenshot 2023-01-09 at 11 44 22 AM

For minutes.

Meanwhile, gopls is using 4-8 GB or more of memory and using tons of CPU.

perf top says:

Screenshot 2023-01-09 at 11 44 54 AM

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.

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Jan 9, 2023
@gopherbot gopherbot added this to the Unreleased milestone Jan 9, 2023
@renthraysk
Copy link

Similar experience. Saving whilst not having a go.mod file present grinds to crawl.
I believe this is #56496 related.

@bradfitz
Copy link
Contributor Author

Well, I have go.mod files.

@findleyr
Copy link
Contributor

Gopls is generally resource hungry on large (or even medium large) workspaces. Furthermore, it is sensitive to which directory you open.

Couple questions:

  • Which directory do you open, relative to your go.mod files?
  • How many files / packages do you have in your module / workspace?

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.

@josharian
Copy link
Contributor

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. :/

@findleyr
Copy link
Contributor

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 adonovan modified the milestones: Unreleased, gopls/v0.12.0 Jan 12, 2023
@adonovan adonovan added the gopls/performance Issues related to gopls performance (CPU, memory, etc). label Jan 12, 2023
@adonovan adonovan self-assigned this Jan 12, 2023
@joel-rieke
Copy link

joel-rieke commented Jan 26, 2023

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.

@findleyr
Copy link
Contributor

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.

@joel-rieke
Copy link

joel-rieke commented Jan 26, 2023

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! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls/performance Issues related to gopls performance (CPU, memory, etc). gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

7 participants