I second this.

Whilst using gopls, I notice a steady increase of memory until it OOMs my system (which has 30GiB spare). I've been using gopls on the go compiler itself, and on the x/tools repository. I regularly have to kill gopls to prevent it from using too much RAM.

CC @stamblerre @ianthehat

We are currently working on a number of improvements to gopls, particularly caching, which should solve a lot of these issues. As of right now, gopls calls go/packages.Load on every keystroke, which is likely why it requires so much memory. There should be updates on this soon.

Change https://golang.org/cl/164779 mentions this issue: internal/lsp: handle initializationOptions

Change https://golang.org/cl/165438 mentions this issue: internal/lsp: add cache for type information

I'm trying latest master branch with same file.

memory usage is improved considerably. And completion seems to be faster.

Closing for now, we can reopen as needed.

Is this normal? I get 7gb usage from gopls.exe

This also happened to me; wasn't actively using vscode at the time:

It kept using more memory until the machine was OOM.

Also in Ubuntu

What is the size of the projects that you were working on? gopls caches type information so the larger the project, the more memory it will use. It shouldn't keep using more memory or OOM, however, unless you are consistently adding new dependencies.

@stamblerre My go.mod has around 70 dependencies.

@stamblerre I have about 10 dependencies
I don't if the information below will be helpful
Screenshot from 2019-05-11 16-16-00

Screenshot from 2019-05-11 21-12-32

I had a few projects with modules open with ~70 dependencies between them.

I have around 10 dependencies and memory goes up to 1GB right away

I have experienced similar issues for what it is worth, ubuntu works flawlessly running with <1gb ram but initially running in windows quickly ate all available ram rendering gopls inoperative. Recent updates have improved this significantly, now gopls will only use ~5gb with ~40 dependencies for a single project.

We have a few pending changes that will hopefully improve the memory consumption - I will update this issue once these changes are submitted.

Change https://golang.org/cl/178719 mentions this issue: internal/lsp: trim ASTs for which we do not require function bodies

The change above was the first of these planned improvements. It would be really helpful to get feedback on it. Did memory consumption decrease for anyone on this thread?

I switch to Windows from Linux (Ubuntu) recently and I haven't notice any lag since then

(setq lsp-gopls-server-args '("-rpc.trace" "--debug=localhost:6060")) should do the trick.

Yep, that's what I have -- when I tried it last week it wasn't having any effect.

Hopefully this is on the right track:

 Main Info Memory Metrics RPC Trace
GoPls memory usage
Stats
Allocated bytes	1,874,759,688
Total allocated bytes	27,826,168,120
System bytes	5,422,058,296
Heap system bytes	3,823,140,864
Malloc calls	328,987,833
Frees	309,344,009
Idle heap bytes	1,664,188,416
In use bytes	2,158,952,448
Released to system bytes	15,638,528
Heap object count	19,643,824
Stack in use bytes	1,344,241,664
Stack from system bytes	1,344,241,664
Bucket hash bytes	3,228,582
GC metadata bytes	190,748,672
Off heap bytes	9,416,594
By size
Size	Mallocs	Frees
0	0	0
8	5,937,615	5,463,178
16	62,172,147	59,529,419
32	105,959,191	99,970,666
48	32,586,016	29,370,218
64	23,455,382	22,104,325
80	11,692,136	10,895,865
96	4,782,414	3,965,587
112	1,251,115	1,175,280
128	3,514,623	3,382,241
144	14,696,691	13,772,588
160	9,697,051	9,606,337
176	8,473,294	7,405,670
192	4,022,748	3,916,726
208	6,710,206	6,634,774
224	4,886,396	4,113,227
240	512,857	388,860
256	611,621	509,291
288	941,235	763,448
320	530,070	430,645
352	342,435	260,203
384	765,073	284,602
416	182,057	160,201
448	76,485	68,972
480	58,594	56,157
512	101,509	98,480
576	37,235	35,434
640	30,912	30,313
704	22,933	22,523
768	6,832	6,670
896	28,810	28,071
1,024	66,962	65,195
1,152	9,491	9,118
1,280	8,060	7,920
1,408	5,744	5,616
1,536	10,193	10,054
1,792	69,264	68,793
2,048	36,226	35,270
2,304	11,438	11,228
2,688	5,422	5,235
3,072	4,625	4,476
3,200	1,478	1,446
3,456	4,391	4,309
4,096	50,499	49,535
4,864	5,826	5,614
5,376	3,458	3,330
6,144	4,673	4,502
6,528	1,686	1,640
6,784	1,007	981
6,912	746	723
8,192	70,139	69,641
9,472	4,297	4,131
9,728	341	325
10,240	4,214	4,130
10,880	959	928
12,288	3,282	3,230
13,568	3,809	3,742
14,336	2,882	2,741
16,384	5,253	5,111
18,432	2,991	2,949
19,072	1,126	1,098

I think this was related to goimports again -- changing the parameters of a function.

lsp-mode config:

(use-package lsp-mode
  :ensure t
  :hook (go-mode . lsp)
  :commands lsp
  :config
  (setq lsp-gopls-server-args '("-rpc.trace" "--debug=localhost:6060")))

go-mode config:

(use-package go-mode
  :ensure t
  :bind-keymap
  (("C-c t" . go-tag-add)
  ("C-c T" . go-tag-remove)
  ("C-c C-b" . pop-tag-mark))
  :config
  (add-hook 'before-save-hook #'gofmt-before-save)
  (add-hook 'go-mode-hook 'flycheck-mode)
  (add-hook 'go-mode-hook 'dumb-jump-mode)
  (if (executable-find "goimports")
      (setq gofmt-command "goimports"))
  (setq go-tag-args (list "-transform" "camelcase")))

I'm going to try setting go-mode to use gofmt instead of goimports and see if there's any improvement.

gopls should be able to perform import organization for you, so you should not need to run the goimports binary separately. https://github.com/golang/tools/blob/master/gopls/doc/emacs.md has the information on how to configure this. This doesn't explain the gopls memory usage, but it may help since it will de-duplicate some of the work your machine is doing.

Thank you. I didn't notice any issues with memory usage after removing goimports from my go-mode config. I've just added the save-hooks specified in the docs and will see how things go.

Unfortunately, it looks like I'm still running into memory usage issues. I think this was related to imports again -- a typo in accessing a struct field seemed to cause a spike in CPU and memory usage. I had to manually kill gopls to get control back.

Hope this is still helpful:

 Main Info Memory Metrics RPC Trace
GoPls memory usage
Stats
Allocated bytes	3,513,551,600
Total allocated bytes	23,534,938,824
System bytes	7,178,594,392
Heap system bytes	4,375,805,952
Malloc calls	248,781,847
Frees	209,081,325
Idle heap bytes	814,415,872
In use bytes	3,561,390,080
Released to system bytes	22,593,536
Heap object count	39,700,522
Stack in use bytes	2,468,151,296
Stack from system bytes	2,468,151,296
Bucket hash bytes	3,214,374
GC metadata bytes	251,400,192
Off heap bytes	12,192,818
By size
Size	Mallocs	Frees
0	0	0
8	5,084,837	4,311,387
16	48,989,694	41,724,412
32	71,900,063	61,706,671
48	26,418,769	20,442,178
64	19,835,705	17,607,378
80	10,926,038	9,475,692
96	5,458,456	3,835,888
112	928,812	798,434
128	2,195,352	1,903,198
144	11,638,153	8,902,226
160	6,965,488	5,972,364
176	7,282,924	5,039,367
192	3,011,182	2,487,809
208	4,960,396	4,364,049
224	2,188,038	1,503,377
240	418,976	192,544
256	678,848	474,599
288	1,350,681	983,676
320	547,058	340,549
352	411,855	239,361
384	961,807	253,902
416	218,154	165,008
448	64,591	43,486
480	172,986	162,323
512	106,509	100,322
576	50,746	46,541
640	38,054	36,929
704	15,882	15,444
768	7,102	6,838
896	49,097	48,353
1,024	59,821	58,282
1,152	18,140	17,791
1,280	5,736	5,646
1,408	13,189	13,047
1,536	5,326	5,216
1,792	84,438	83,832
2,048	31,352	30,071
2,304	12,648	12,396
2,688	9,108	8,895
3,072	3,511	3,432
3,200	2,577	2,530
3,456	2,503	2,430
4,096	45,466	44,136
4,864	10,538	10,354
5,376	3,718	3,629
6,144	5,584	5,509
6,528	1,669	1,633
6,784	751	734
6,912	1,739	1,718
8,192	67,701	67,056
9,472	6,654	6,510
9,728	338	320
10,240	3,435	3,383
10,880	699	677
12,288	4,225	4,179
13,568	2,446	2,370
14,336	7,685	7,570
16,384	5,643	5,509
18,432	1,928	1,887
19,072	1,774	1,744

(use-package go-mode
  :ensure t
  :bind
  (("C-c C-b" . pop-tag-mark)
   ("C-c t" . go-tag-add)
   ("C-c T" . go-tag-remove))
  :config
  (defun lsp-go-install-save-hooks ()
    (add-hook 'before-save-hook #'lsp-format-buffer t t)
    (add-hook 'before-save-hook #'lsp-organize-imports t t))
  (add-hook 'go-mode-hook 'dumb-jump-mode)
  (add-hook 'go-mode-hook 'flycheck-mode)
  (add-hook 'go-mode-hook #'lsp-go-install-save-hooks)
  (setq go-tag-args (list "-transform" "camelcase")))

(use-package lsp-mode
  :ensure t
  :hook (go-mode . lsp)
  :commands lsp
  :config
  (setq lsp-gopls-server-args '("-rpc.trace" "--debug=localhost:6060")))

Yes, those numbers do seem problematic. Are you working on a public project that I can try reproducing on or is this private code?

Also, do you experience the same issues at master? You can get master by running GO111MODULE=on go get golang.org/x/tools/gopls@master golang.org/x/tools@master.

Unfortunately I'm working on private code. I'll try and see if I can get the behavior to trigger in a public codebase, though. I'll also set up master now -- thank you.

It also happens to me ... 10G +... It is easy to reproduce, git clone https://github.com/asticode/go-astilectron-demo, With vscode, remote SSH to open this folder, open message.go and main.go files and scroll to browse the code. In one minute the memory will increase to 10G (insider version), while with release version of vscode, the memory up to 7.6G.

@ajeecai: What version of gopls are you using (gopls version)? You report sounds like a memory leak that existed a few months ago. If you update to the latest version (GO111MODULE=on go get golang.org/x/tools/gopls), I don't think that you should see this behavior.

Hi @stamblerre Is this the latest version? I don't know how to update standalone gopls and what is its latest version.

@ajeecai: v0.2.2 is the latest released version, though we will be releasing an update sometime this month. If you'd like to try out the current master, you can run: GO111MODULE=on go get golang.org/x/tools/gopls@master golang.org/x/tools@master.

hi @stamblerre , with this command, the version of gopls looks downgrading

But as I edit the code in vscode, the memory usage looks extremely high, worse.

Do you have any change to try with the project I code mentioned, I think it is easy to reproduce.

@ajeecai: I am not able to reproduce with the example you've given, but it's possible there are other factors at play here. Can you share you enable debug logging and share your gopls logs here? See https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs for more information. You can also enable the debug server, and we can try seeing what is using that much memory.

I have switched gopls back to 0.2.2, when the memory up to 9G, I have followed the instructions and captured the log information in attachments. Please take a look.
gopls_log.txt
gopls_6060.tar.gz

Thanks

Thank you for sharing this - something does appear to be going very wrong here, as the memory usage really is high, and you'll notice that there are many cancellation requests in the log, indicating that something is probably hanging. I'm afraid I won't be able to make much more progress in investigation without memory profiles, so if you'd be willing to collect some that would be very helpful. This can be done by running go tool pprof -web http://localhost:6060/debug/pprof/heap while gopls is running.

I would also highly recommend sticking with master (the v0.1.8 number was correct, sorry that it is misleading). A lot has changed since v0.2.2 came out, so I hope that might have some effect.

This issue is almost a year old, and a great deal has changed in gopls since that time. There are a lot of discussions here that are no longer relevant, so I am going to close this issue and use #36943 to track general memory improvements.

If you encounter a specific issue with your project, please open a new issue so that we can begin discussion separately.

@ajeecai: If you are able to produce profiles, please do create a new issue to share them, and we will continue investigating.