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: v0.4.4 stops working after some period of time #40567

Closed
mrunhap opened this issue Aug 4, 2020 · 23 comments
Closed

x/tools/gopls: v0.4.4 stops working after some period of time #40567

mrunhap opened this issue Aug 4, 2020 · 23 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@mrunhap
Copy link

mrunhap commented Aug 4, 2020

gopls 0.4.4 consumes tons of memory!

And it killed my computer.

@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 Aug 4, 2020
@gopherbot gopherbot added this to the Unreleased milestone Aug 4, 2020
@mvdan
Copy link
Member

mvdan commented Aug 4, 2020

You should provide some more detail. What Go version? What were you doing? How can the developers reproduce this issue?

@mvdan mvdan added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 4, 2020
@ainar-g
Copy link
Contributor

ainar-g commented Aug 4, 2020

Not the OP, but here are some of my measurements. Opening staticcheck source code and making a couple of edits, with v0.4.3:

$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
  98049 gopls serve                 169016 1450036

Same things with v0.4.4:

$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
  98956 gopls serve                 212648 1451360

I'm opening cmd/staticcheck/staticcheck.go on tag 2020.1.5, using Vim 8.1 with the natebosch/vim-lsc plugin.

UPD: Here are the numbers from the etcd repo:

# v0.4.3
$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
 101854 gopls serve                 299244 1661956
# v0.4.4
$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
 100923 gopls serve                 356384 1662964

@stamblerre
Copy link
Contributor

@ainar-g: What is your workspace root when you open these files? Is it the module root or a subdirectory?

@ainar-g
Copy link
Contributor

ainar-g commented Aug 5, 2020

@stamblerre That doesn't seem to matter much. Using the same staticcheck example, launching Vim from the cmd/staticcheck subdir:

$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
 234017 gopls serve                 225928 1519328

Launching Vim from project root:

$ ps -opid,cmd,rss,vsize -p $(pgrep gopls)
    PID CMD                           RSS    VSZ
 234276 gopls serve                 228060 1445404

@stamblerre
Copy link
Contributor

The reason I ask is that gopls/v0.4.3 only loaded the packages in the directory you opened in the editor, whereas v0.4.4 loads the entire module, no matter which directory you open. I'm guessing that might be the cause of the increased memory usage you are seeing.

@ainar-g
Copy link
Contributor

ainar-g commented Aug 5, 2020

Can confirm, opening from the module root with v0.4.3 produces the same memory usage, so I guess my question is solved. Not sure about the OP's though.

@stamblerre
Copy link
Contributor

Glad that resolved it!

@404CN: Please follow the steps in the troubleshooting guide and provide the relevant information so we can investigate.

@ilkeraksu
Copy link

ilkeraksu commented Aug 5, 2020

The reason I ask is that gopls/v0.4.3 only loaded the packages in the directory you opened in the editor, whereas v0.4.4 loads the entire module, no matter which directory you open. I'm guessing that might be the cause of the increased memory usage you are seeing.

we have mono repo and single module.
I only add only sub packages to VS Code as folder.

I had to revert to gopls/v0.4.3 due to excessive memory usage. It went up 16 GB from 1,5GB

UPDATE: quick test again. It is ( gopls/v0.4.3) 781MB vs. (gopls@v0.4.4) 3.80 GB ( Real Mem 2,50 GB)

Any suggestion for mono repo?

@stamblerre
Copy link
Contributor

@ilkeraksu: Thanks for the report. This is something we didn't really consider when making this change. I think for v0.4.5, we will add a setting that users working in larger modules can configure to limit their workspace scope.

@stamblerre stamblerre changed the title x/tools/gopls: 0.4.4 consumes tons of memory! x/tools/gopls: add configuration to limit workspace scope to rootURI Aug 5, 2020
@stamblerre stamblerre removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 10, 2020
@gopherbot
Copy link

Change https://golang.org/cl/247617 mentions this issue: internal/lsp: add a configuration to limit workspace scope to root URI

@stamblerre
Copy link
Contributor

@ilkeraksu: You should now be able to update to gopls at master (GO111MODULE=on go get golang.org/x/tools/gopls@master golang.org/x/tools@master) and add the following to your settings:

"gopls": {
    "expandWorkspaceToModule": false
}

@ilkeraksu
Copy link

@stamblerre Thank you for quick fix.

this setting prevented execessive usage ( otherwise computer went crazy )

Maybe another issue,
But some behaviour changed badly from 0.4.3 to 0.4.4. Intellisense working intermittently , works for 3-4 seconds then stops for a while up to 1-2 minutes then work for 3-4 secods again

I would like to elaborate our usage for understanding,

  • MonoRepo
  • Single module, placed in the root
  • Lots of apps and packages
repo
 + go.mod
 + go.sum
 +-packages
 	+-package01
        + ....
	+-package N
 +-services
 	+-service1
 		+-package01
                + ....
 		+-package N
 	+-service2
 		+-package01
                + ....
 		+-package N
 +-tools
 	+-tool1
 		+-package01
                 + ....
 		+-package N
+ ...

Usually we work on 2-3 services at once so
Create vscode workspace for main task at hand
Add related services to workspace
Add related packages as needed

Of course we have 5-6 utility kind, supporting packages always used (imported) in almost every where ( like errors, logging etc)
and these packages is not included in workspace

@stamblerre
Copy link
Contributor

Thanks for the clarification - that makes sense. This new configuration should work for your use case.

I'm not sure what would've changed to cause features to stop working. Can you please attach your gopls logs from when you see this happening? Instructions on how to capture them can be found here.

@stamblerre stamblerre reopened this Aug 11, 2020
@stamblerre stamblerre added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 11, 2020
@ilkeraksu
Copy link

Hi @stamblerre ,

These are logs when I typed dev.P expecting complete methods . Typed 1 seconds apart each key.
package "su/pkg/dev" already imported and also included as folder in workspace
I tried to keep try small if you need more I can get more

2020-08-12-10-56 _gopls.txt

@stamblerre
Copy link
Contributor

@ilkeraksu: Do you mind providing a log that starts at the time that gopls is started? I don't see anything obviously wrong in the log you provided, but there may be errors logged when gopls initializes the workspace.

@ilkeraksu
Copy link

Hi @stamblerre ,
Full log attached .
Again intermittently could completed and failed to complete

most of the time I tried e.E and dev.P . These packages were already imported.

Hope this helps,
Thank you
2020-08-13-16-00_gopls.txt.zip

@gopherbot
Copy link

Change https://golang.org/cl/248400 mentions this issue: internal/lsp: check for context cancellation before showing messages

@stamblerre
Copy link
Contributor

I did find one issue, which will be fixed in https://golang.org/cl/248400, but I didn't notice anything that stood out to me in your logs.

Do you have a repro case possibly? When completion stops working, is it in all cases or only some? Do other features stop working too?

gopherbot pushed a commit to golang/tools that referenced this issue Aug 13, 2020
Noticed this as part of investigating golang/go#40567.

Change-Id: I977b1b0a6ceb139e35e087c16b6ab88d66af69a9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248400
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@ilkeraksu
Copy link

Looks like problem arise under stress,
We usually do pair programing, zoom is open and screen shared most of the time.

with 0.4.3, I don't have this issue

with 0.4.4, Under CPU and Memory stress. (zooom open) I have problem
( 8GB RAM, gopls use 1.13 GB Real Mem 1,5 GB swap used, but activity monitor Memory Pressure is green )

with 0.4.4 no CPU stress, zoom closed, no problem.

When problem happens other features seem to work, like going definition or hover can show func signature

we may have some kind of timeout problem ( my two cents)

@stamblerre
Copy link
Contributor

To clarify, when you say v0.4.4, do you mean exactly v0.4.4 or master with expandWorkspaceToModule set to false?

@ilkeraksu
Copy link

With 0.4.4 I mean master with expandWorkspaceToModule set to false.

@stamblerre stamblerre removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 15, 2020
@stamblerre
Copy link
Contributor

Thanks for clarifying. It might be easier to understand if you can produce a smaller log that demonstrates the issue. @heschik also mentioned that the issue may be related to your Dropbox workspace folder, but if the issue doesn't reproduce with v0.4.3 that might not be a likely explanation. Still, it may be worth checking if you can link the issue back to a specific one of your workspace folders, since there are many.

@stamblerre stamblerre changed the title x/tools/gopls: add configuration to limit workspace scope to rootURI x/tools/gopls: v0.4.4 stops working after some period of time Aug 17, 2020
@stamblerre stamblerre added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 25, 2020
@stamblerre
Copy link
Contributor

Closing as this is in the WaitingForInfo state and gopls/v0.5.0 will be released soon. Please open a new issue if you still have this issue with gopls/v0.5.0-pre3 (GO111MODULE=on go get golang.org/x/tools/gopls@v0.5.0-pre3.

@golang golang locked and limited conversation to collaborators Sep 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

6 participants