go-langserver uses lot of cpu and this causes vscode to hang or slow responsiveness #209
Comments
|
Thanks for the report @chandradeepak as well as the profile. How does the resource usage compare to the reference finder without the language server? Our reference implementation is a modified version of the reference finder in go guru (what the plugin uses). When did you install the language server? We did some major updates a few months ago which should help a lot with resource usage, so just in case you have an old lang server binary hanging around I'd suggest updating. |
|
The trace seems to point to most of the time spent reading files. Right now the implementation relies on the go typechecker. It shouldn't do more work than go does to compile your application. IS the time take a similar amount of time without a pkg cache? |
|
what is a pkg cache? Not sure what it is. I know my language server is latest it was installed on Nov 6th 2017. |
|
Sorry, I missed your reply. @chandradeepak if you still have this issue, how does the perf compare to just vscode-go without the langserver? You say you have 50 files, how many files are on your GOPATH though? |
|
@keegancsmith , vscode-go would be smooth until i change some files with out langserver . But it has some other issues as well. In my GOPATH i have so many repos. Do you think that is the cause ? |
|
@chandradeepak To clarify what @keegancsmith said above a bit: If you disable the language server in vscode-go settings and just use vscode-go without language server, how slow is find references in comparison? Note: We do have someone who is taking a look at improving find references performance, but it's a very tough problem to solve and as such there is no ETA on when it may be completed right now. |
|
Is anyone exploring this at this moment? |
|
In order to fix this issue, we will need to switch over to using the new golang.org/x/tools/go/packages package. Almost all of the CPU and memory usage from go-langserver comes from type-checking, and using that package would reduce it substantially as it would cache results to disk automatically AFAIK. Nobody is working on this issue right now AFAIK, and it'd probably be quite a large undertaking as it would affect almost the entire codebase I think -- but we'd be very open to someone trying to contribute this. 😃I can't give any guarantees or hard dates, but I think we are likely to work on this in a few months or so if nobody beats us to it. |
|
Looking at the documentation on go/packages it says it's not production ready and has dependencies on Go 1.11. The idea is to wait until it gets stable? |
|
The warning about it not being ready for widespread use yet seems to be mostly about the fact that the API may change, which is OK for us (we can vendor it anyway). If we use it before it supports older Go versions, we'd need to use it optionally at build time. e.g. when building with Go 1.11, it would use that package and when using an older version it would use our current go/loader setup. |
|
I am experiencing high CPU usage from this recently. I have vscode up and running in the background, on a different desktop, and go-langserver shows up as using 50% of a CPU on my Mac in the activity monitor. |
|
Mine goes as high as 400% every 10m. It's not usable. |
|
The go-langserver uses 800% cpu (8 cores) and 15GB mem (16GB total) on my MBP. It happens in this month, I do not know why it happens |
|
Can you share your config? Have you enabled any optional features like code completion or diagnostics? |
|
I write Go file by vscode, here is my settings.json BTW, there are 1281 Go files in my project, too much files ？ |
|
You are not opting into anything that should make go-langserver that slow. 1281 files should be fine. We run go-langserver on sourcegraph.com and don't use as much resources for large projects such as kubernetes. We won't have time to investigate these perf issues in the short-term, so I would suggest disabling the go language server in vscode-go in the mean time. There should hopefully be a new go language server in the not too distant future which won't suffer from such issues. See #316 (comment) |
|
I have the same issue, it goes almost up to 600% cpu usage, I have almost 2000 files in a project. |
|
@sp4rd4 for now just disable the language server. If your performance improves report back here. |
|
I ran dtruss on go-langserver to see why it is using so much CPU. I saw that it was churning over and over the Go source files in GOROOT. I moved the Go src files to a different place, and the CPU usage became ok. Of course this means that I can't get doc info for standard library stuff, but I can atleast go through my own code. I cannot disable language server, it is the only alternative which currently supports symlinks in GOPATH, and that it critical for me. I wish the langserver would read GOROOT/src only once during startup and not watch those directories afterwards. The number of open/fstat64 going on was ridiculous. |
|
@sandipb thanks, that is a good lead on what is going wrong and surprising to me. If you re-install the langserver using the same version of Go you are developing with do you still have issues? |
|
I have configured vscode to compile go-langserver using the executable for the project in a version specific tools directory. So it is compiled with the same version. Just to confirm, I used Confirmed that it is the same version. |
|
It seems I managed to calm I'll update if it goes crazy again |
|
It's not better. It also caused a kernel panic |
|
Yeah, I can confirm. I have had one panic reboot when I let go-langserver run at top cpu load for too long. |
|
I noticed that the golang servers that start to go crazy actually panic It seems to panic, then it goes berserk on the CPU |
|
this diff should prevent the panic at least diff --git a/langserver/loader.go b/langserver/loader.go
index f030f90..a0f50c5 100644
--- a/langserver/loader.go
+++ b/langserver/loader.go
@@ -122,6 +122,11 @@ func posForFileOffset(fset *token.FileSet, filename string, offset int) token.Po
if f == nil {
return token.NoPos
}
+
+ if offset > f.Size() {
+ return token.NoPos
+ }
+
return f.Pos(offset)
} |
|
While it certainly fixes the panic, go-langserver is still eating all cpu and memory... |
|
I'm also having this issue on Mac High Sierra 10.13.6. Seems like a memory leak. My CPU usage is low, but memory usage climbs until the os crashes. |
|
The only way to make it usable for me with vscode is to kill it every 60s in a background bash loop |
|
One odd thing stood out from looking at the trace log - currently, when I am typing in the code editor, it seems that vscode sends a Is this by the protocol design? Could this be causing some concurrency issues? e.g. before the previous requests is handled properly, the next one comes along? Can this be, in some ways debounced on the server side? |
|
I saw the goroutine count top 4000 as well as memory usage go past 5GB. Attaching allocs, heap dump and goroutine dump |
|
Adding a CPU profile for the craziness today morning. |
|
Having the same issue. From what I saw so far, it especially happens when I type in code, quickly revert it and then either wait or continue typing again. |
|
me too |
|
Same here, go-langserver consumes about 8-10Gb of memory in few minutes. |
|
FWIW, I've noticed that this is an issue on OSX, but not on ubuntu-based (debian-based?) linux distros, such as Elementary OS. Not sure what the difference is there. I'll need more time to compare dependency versions between the two test machines. |
|
Happening on MacOS 10.14.1 too |
|
happening on ubuntu 16.04.1 here too |
|
@zephinzer interesting. It doesn't happen to me on elementary os 5, which is ubuntu based. |
|
Happening on MacOS 10.14.3 too 😢 |
|
A go language server from Google's go tools team is close to being ready. If you are blocked, maybe try out gopls |
|
Happening on macOS 10.14.5 |
Macbook
OS x EI Captain
Attached is the cpu profile .
It shows lot of time spent in reading files not sure why that happens but i have seen this slows the find references in vscode very slow. I have almost 50 files in a project.
let me know if you need any thing else
The text was updated successfully, but these errors were encountered: