x/tools/gopls: high cpu usage all the time #70172
Labels
gopls/imports
gopls
Issues related to the Go language server, gopls.
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
newhook
added
gopls
|
Is the workspace open source code? If so, can you tell us what repo/commit triggers the bug? Thanks. |
|
The source code is closed source and it is ~1mio loc. The issue doesn't appear to be related to open files since it occurs even if I have no files open. On startup I can see it running go alot (I guess running go list), and then evetually that stops and It stablizes at 400% CPU. |
|
Were you able to get the output of |
|
ansaba
added
the
NeedsInvestigation
|
Gopls should (eventually) stop consuming CPU, once it's done indexing your workspace. Does the CPU spike after every keystroke? If so, I can help you capture a profile. |
Yes, but it does not. It stays at 400% CPU all the time, whether or not I'm doing anything. Even after hours of not doing anything. |
|
Could you send the process a SIGABRT after the initial workspace load (a minute after startup should be plenty) and share the stack trace it prints to stderr? That would give us a clue about what loops are active. |
|
I've run goprof manually and attached cursor to that. Any other flags I should provide to gopls to get more debugging information Right now gopls is using very high CPU. Looking at the ps shows me that gopls has forked go mod tidy of the following module file (in a temporary directory). Looking at the stacks: |
|
Thanks! A lot of threads are walking your GOMODCACHE, which appears to be quite large. You might want to try |
|
P.S. It is surprising that there are so many frames on the WalkDir stack--more than 18 in some threads. This means some modules contain very deep directory hierarchies. You might be able to find out which module is the culprit by running a command to display the file names provided to the system calls. On linux you can use |
|
Thanks for the help so far! I did have a very large gomodcache, so I cleaned that, but it didn't seem to fix the problem. Running For example. Why would gopls be traversing my entire filesystem? I tried again a couple of minutes later: |
|
Thanks for the data, this is very helpfui.
No good reason: this is definitely a bug. Seems like the module resolver has escaped the mod cache. What set of .go files do you have open? I wonder if somehow one of them is in the root of a very deep tree (e.g. "/a.go"). I notice that gopathwalk.Walk claims to follows symbolic links (!!): so if any of your source or module directories contains a link to, say /, this could spell trouble @findleyr will certainly have more ideas. |
|
In this case I don't have any go files open in cursor (I closed them all to see whether that was causing the problem). Let me check for symlinks! and also none in the source code repo either. |
|
Can you share any gopls settings that you are using? Gopls used to scan the file system in many places, but a while ago I cleaned (most) of these up. Now the only two places I'm aware of where gopls will walk the filesystem is (1) module cache scanning and (2) looking for template files, which only occurs if you have |
|
I don't think I'm using any gopls specific settings. |
|
Ok, well this certainly looks like a runaway modcache scan. Can you start gopls with I would also like to send you a patch that completely disables the module cache scan. If that fixes the problem, we can be certain of the cause. |
|
Moving this to v0.18.0, as my hope is that we will rewrite the entire goimports scanning logic for that release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
gopls version
0.16.2
go env
What did you do?
open cursor on a go project. goplus is constantly at 200-400% cpu, even if I'm not doing anything.
What did you see happen?
high cpu usage.
What did you expect to see?
not high cpu usage.
Editor and settings
No response
Logs
No response
The text was updated successfully, but these errors were encountered: