-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/gopls: gopls becomes unresponsive from time to time #61969
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
Comments
@dppascual are you definitely observing this with gopls@v0.13.1? That release specifically fixed several root causes that could lead to slow code actions. The only remaining cause of such behavior is the goimports cache (#59216), but that should be relatively rare. Are you observing this a lot?
Do you know if this message is only shown by neovim during initialization? That could indicate a gopls crash followed by a reinitialization. |
Yes, if you observe the path of the gopls printed out in the log, it points to gopls@v0.13.1
The last working day it happened to me about three times.
No, it is shown when I request a code action for organising imports or filling up a new struct, among others. @findleyr Let me continue digging down into such problem and collecting more info since the gopls is initialized until the errors comes up again. The size of the log could be huge but it will contain the whole trace and help us to identify what's going on. |
@dppascual sorry for not being clear. I did observe that, but wondered if perhaps you were reporting on issues observed in the past, before the update. Thanks for clarifying.
Thank you! We will take a look. |
Sorry, have been backlogged with work. Finally got a chance to dig into this today. Here's a critical section of the logs:
In summary:
Based on this, I suspect:
The 20s interval is suspicious: if we can figure out where that delay/timeout is coming from, it may lead us to the root cause. Of course, it may be coincidental. @dppascual something you can do to help us narrow this down is the following: start gopls with CC @adonovan |
Putting this in the v0.14.0 milestone as it would be good to track this down ASAP. With that said, I don't currently have ideas how to proceed. I don't experience this in my day-to-day development. From the logs, there definitely appears to be a bug somewhere, but we need more information to track it down. |
@findleyr I've been coding the last two weeks against the latest version of gopls (0.13.2) and I haven't experienced any latency problem. Also I enabled the plugin that was causing the error to appear most frequently but the issue is not reproduced, the server responds in a reasonable time. Looking at the changes of the latest version of gopls, it is a minor version that applies a concrete bugfix so it should not be related to the mentioned problem. It happened to me with the previous version (0.13.1) but I've not tested such version again after updating to the latest one. I propose to keep this issue open until the next version is released and if the error comes up, I will bring it here with more info. |
hey @findleyr, during the last working day I started to observe that On the other side, I want to mention two other issues non related to this one:
Just mentioning them here because the attached report can shed some light. Let me know if you need more info to track it down. |
Thanks @dppascual The autocomplete problem is (I believe) understood, and I have fixes on the way (#62665). I'll highlight one thing that may be related: 1m49s for source.AllImportsFixes. That indicates an enormous time spent in goimports -- longer than I've seen before. Other metrics look similarly unhappy: 30s to run the Go command?! Could you run |
@findleyr I don't see any sensitive info that I cannot share so here it is:
|
Thanks. That's not a particularly large workspace. I'm really surprised by how slow the initial workspace load is. I'm equally surprised by the slowness observed in your traces above for imports scanning and running the Go command. Could you run the following from your workspace root?
Right now, I am suspicious of a slow file system, as all the operations that are abnormally slow interact with the file system in some way. Does that ring any bells? |
Right now I have to go, it is the time the executed command has spent:
I will run some benchmark on my filesystem and upload the report. |
Hi @findleyr, sorry for my late reply, I've been very busy at work. You were right, it was caused by slow read operations. When it was fixed, the times were drastically reduced, and the coding became smooth. Also, I've tried completion operations by using gopls@master and the exported values of the package introduced were popped up relatively quickly. Here is the new result of
I guess it makes more sense to you, don't you? |
Thanks @dppascual, that looks much better! Out of curiosity, what was the cause of the slow reads? |
(I'll close this as resolved. Please let me know if I'm misunderstanding.) |
Hi @findleyr, The initial reason was because the SSD was under 20% free space, it made my computer slow down and became unresponsiveness because of how SSDs use caching to be fast. It usually causes performance impact on write operations, but read ones were affected as well. After freeing some space, gopls started to response super fast, but right now it is happening again. I'm super sure my disk is causing this slowness because I'm also suffering how slow the neovim startup is , it takes ~= 7s, when it should be close to ms. Having said it, the issue can be keep closed. Thanks for your help. |
gopls version
go env
What did you do?
I haven't found any solid pattern yet that evidences why it is happening, but I have a vague feeling that it could be caused by any condition when code actions are requested. I had to disable the plugin `https://github.com/kosayoda/nvim-lightbulb' (basically, it shows a lightbulb whenever a code action is available at the current cursor position) because it was causing such anomaly happened more frequently.
Also, I have configured an autocommand that execute the code action
organize imports
each time the file is saved. This action has been always executed when the anomaly comes up, but it doesn't mean the anomaly happens every time the action is executed.What did you expect to see?
The server
gopls
should send back a response for every method requested by the client.What did you see instead?
When it happens, completions|diagnostics|code actions stop working for a while (30 seconds or so, and sometimes, even minutes). The editor shows up the following message
Server for client 'gopls' not yet ready!
Editor and settings
Editor:
gopls:
Logs
The text was updated successfully, but these errors were encountered: