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

[404cn]

gopls 0.4.4 consumes tons of memory!

And it killed my computer.

[mvdan]

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

[ainar-g]

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]

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

[ainar-g]

@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]

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]

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]

Glad that resolved it!

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

[ilkeraksu]

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. ([email protected]) 3.80 GB ( Real Mem 2,50 GB)

Any suggestion for mono repo?

[stamblerre]

@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.

[gopherbot]

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

[stamblerre]

@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]

@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

 + 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]

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.

[ilkeraksu]

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]

@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]

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]

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

[stamblerre]

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?

[ilkeraksu]

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]

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

[ilkeraksu]

With 0.4.4 I mean master with expandWorkspaceToModule set to false.

[stamblerre]

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]

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/[email protected].