[GODRIVER-2750] High goroutine count in connection read/write Created: 06/Feb/23 Updated: 01/May/23 Resolved: 01/May/23 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | None |
| Affects Version/s: | 1.9.1, 1.11.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Unknown |
| Reporter: | Luke Mauldin | Assignee: | Qingyang Hu |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Documentation Changes Summary: | 1. What would you like to communicate to the user about this feature? |
| Description |
| Comments |
| Comment by Qingyang Hu [ 01/May/23 ] |
|
Hello luke.mauldin@l3harris.com, we appreciate your report and the detailed information. Unfortunately, we neither discovered any significant changes around the suspicious code nor were able to reproduce the high goroutine count. Therefore, we are going to close this ticket. However, please feel free to reopen this one or file a new one if you observe the issue again. Again, we appreciate your support on MongoDB Go Driver. |
| Comment by Luke Mauldin [ 12/Feb/23 ] |
|
| Comment by Matt Dale [ 11/Feb/23 ] |
|
Hey luke.mauldin@l3harris.com thanks for the ticket and the update with lots of detail! I'm going to start looking into this early next week. I have a few questions:
|
| Comment by Luke Mauldin [ 07/Feb/23 ] |
|
Documenting additional information. The original code using tailable cursors was written when Mongo driver v1.0.0 was released and had not been updated since that time. It was using cursor.Next(). I updated the code based on the example ExampleCursor_RemainingBatchLength which uses cursor.TryNext() and cursor.RemainingBatchLength(). Using the updated code seems to have resolved the performance problem. Should the documentation be updated to strongly recommend the use of cursor.TryNext() when using a TailableAwaitable cursor? I am also including a pprof screenshot that I captured during a time when the application was using 100% of one CPU and in an almost locked state. |
| Comment by Luke Mauldin [ 07/Feb/23 ] |
|
Please update the title to: High goroutine count in connection read/write |