[SERVER-55885] Backtrace for a simple aggregate operation has over 100 stack frames before hitting CommandInvocation::run() Created: 07/Apr/21 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Assigned Teams: |
Service Arch
|
||||
| Participants: | |||||
| Description |
|
I've noticed while doing some debugging lately that for simple queries (and presumably for all database commands), that there are a ton of promise/future-related stack frames above the CommandInvocation being run. I will attach an example backtrace that I collected recently (it's too long to fit in the ticket description). This isn't a problem per se, but I'm a bit surprised by the apparent level of complexity. It also seems like this can't be good for performance. Is there any room for improvement here? |
| Comments |
| Comment by Blake Oler [ 23/May/22 ] |
|
We think that PM-2770 will alleviate this behavior by removing some unnecessary future chains/template specializations. We separately need to think about reducing the stack size of futures in general – have a TODO to check if we have any other tickets related we can rope in here. |
| Comment by Ratika Gandhi [ 11/May/22 ] |
|
kyle.suarez@mongodb.com Looks like even in the product sync we decided to just close the ticket. I am moving it to Needs Scheduling again for discussion. cc blake.oler@mongodb.com and lauren.lewis@mongodb.com (current TPM of Service arch). |
| Comment by Kyle Suarez [ 11/May/22 ] |
|
ratika.gandhi@mongodb.com, is there a particular reason why this ticket is closed as Won't Do without a project epic? Reducing the overall size of the future callback stack seems like both a performance benefit and an improvement to stack trace readability / call graph profiling. |
| Comment by Ratika Gandhi [ 20/Apr/21 ] |
|
We are aware of this issue but this may require more work that's project sized. We will discuss with Product and link the epic if and when we have one. |