Sorry, but a couple gigs of usage is not totally out of line with expectations, and I don't see anything obviously wrong in the memory dumps. I think you'd have more luck figuring out why you have 3 copies of gopls running.

cc @findleyr for what seems to be a vim thing based on the -remote usage.

Hmm, I see 9 gopls instances actually: 2 daemons, 3 'sidecars', and 4 'forwarders'. Were you by chance playing around with different configuration? Do you have multiple neovim processes running?

I'm guessing the multiple daemons are due to https://golang.org/issue/41266, unfortunately. Neovim users may be better off not using a daemon until that is resolved (or using a manually started daemon).

Can you please try killing all the gopls instances to test if you experience the same symptoms in a fresh session?

I only have one neovim process running, but as you suspect @findleyr, I have been playing with settings and may have both vim-go and coc.vim using gopls simultaneously?

Immediately after a sudo killall gopls I get two gopls commands, two gopls -remote=auto and one gopls serve -listen unix automatically starting up (watching in htop).

After changing settings to add -remote=auto to the CocConfig here:

"languageserver": {
   "golang": {
     "command": "gopls",
     "args": ["-remote=auto"],
     "rootPatterns": ["go.mod", ".vim/", ".config/nvim/", ".git/", ".hg/"],
     "filetypes": ["go"]
   }
 }

And disabling gopls in vim-go (let g:go_gopls_enabled = 0), things are quite a bit better. I haven't yet started retracing steps and trying one at a time to see what's solving it, though.

I've updated the issue name to be less accusatory of gopls :) looking to be more of an issue with editor integration (unsurprisingly, i'm sure).

I'm glad to hear that things are somewhat better, but it sounds like there are still some improvements to be made.

First, what is your motivation for using multiple plugins with a single editor process? When using gopls, each will have their own LSP session and will send text updates independently. I'd expect this to cause problems like duplicate diagnostics, etc.

Second, which version of vim-go are you using? I'd be interested to know if vim-go is using -remote=auto (which is the default only in recent versions), and if it is connecting to the same daemon. If vim-go uses a different gopls binary or different go binary, or has a different value for $TMPDIR, it will start its own daemon.

If it is intentional to have multiple gopls sessions for a single neovim process, there are things we can try that could significantly increase the amount of shared cache between these sessions, provided they are both on the same daemon (for example, in https://golang.org/cl/260737 I added an experiment that modifies our cache key for type information in such a way that it should now be shared when multiple plugins have gopls sessions).

Let me know. This is an interesting use-case, and I'd greatly appreciate any follow-up you're able to do here.

@findleyr thanks!

what is your motivation for using multiple plugins with a single editor process?

Partially an accident of history, partially intentional: I started with vim-go (on standard vim) last year and liked it. I recently learned about NeoVim and COC - which provides a lot of great highlighting and code completion that vim-go doesn't provide (as far as I know). I like a lot of the features that vim-go does provide - like triggering tests, formatting, linting I've already configured, etc - so I'm keeping it around for now for that reason.

I'd expect this to cause problems like duplicate diagnostics, etc.

Indeed, I ran across this (getting double entries in the COC highlight bubbles). My current configuration seems to be avoiding that issue now.

Second, which version of vim-go are you using?

I believe I'm on 1.24, the latest release.

[...] and if it is connecting to the same daemon [...]

have you seen this? https://github.com/ericwq/golangIDE/blob/master/shared-gopls-daemon.md not sure if that's helpful here.

I've changed things a bit since I last wrote here, but the results still seem positive.

I have the following coc-settings.json (for COC.vim and coc-go)

{
   // [...]
  "go.goplsArgs": ["-remote=auto", "-logfile", "/tmp/gopls.log"],
  "go.goplsPath": "/home/vcavallo/go/bin/gopls",
   // [...]
}

And I've removed the golang languageserver block, which I think means coc-go (which I've since installed) handles the connection to gopls now - yet another wrinkle, but one that seems to be helping! (from here)

So hopefully both vim-go and coc-go are using gopls properly with -remote=auto and using the same binary. But to be honest, once things started working well enough I stopped troubleshooting and got back to work.
If you want to test things out deeper on my system I'm happy to work out some method of doing so with you.

If it is intentional to have multiple gopls sessions for a single neovim process

Nope. I'd like the option to have arbitrary vim/neovim plugins and not have to worry about how many gopls sessions they're starting up. But I realize that will likely ultimately be a plugin config responsibility and not gopls's problem.

Thanks for the update, it's useful to hear the process that led you into this state. Getting daemon discovery right is a fundamentally hard problem, because in some cases we want to have multiple daemons (for example, if there's a version mismatch in the gopls binary). I just want to reduce the friction for plugins to find the right daemon. -remote=auto was supposed to do that, but the changing TMPDIR is a source of friction I wasn't expecting.

I'll leave this open as a meta-issue tracking this problem.

-remote=auto was supposed to do that, but the changing TMPDIR is a source of friction I wasn't expecting.

Looks like this is being tracked in #41266, so going to go ahead and close this issue.

Does anyone have an easy to follow recommendation how to make this problem go way with vim-go (not coc)? Every time I'm working on a large project (https://github.com/openshift/installer), it takes gopls mere minutes to eat out 8-10G of RAM and get killed by OOM killer.

@dtantsur: Please take a look at the memory usage section of the troubleshooting guide and open a new issue.