[DOCS-15743] Investigate changes in SERVER-68803: Add whether SBE is in use to currentOp output Created: 15/Nov/22 Updated: 13/Nov/23 Resolved: 01/Feb/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Alison Huh |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 4 weeks, 5 days ago | ||||||||
| Epic Link: | DOCSP-22091 | ||||||||
| Description |
|
Original Downstream Change Summary Added a queryFramework field to the currentOp output for query and getMore commands. [see comments] Description of Linked TicketIt would be helpful to distinguish whether active queries are using the SBE or classic engines, in case there's ever a problem where SBE specifically is misbehaving, versus the classic engine, when both are running on a mongod depending on the query. I did some investigation into adding flags to currentOp output, so I've added some notes below in case it is helpful. ------------------------------------------------------ The info should be carried across to getMore cmds, so it looks like the info will need to hook into/through the ClientCursor (perhaps a flag on the PlanExecutor the ClientCursor holds). The decision whether to use SBE appears to take place in getExecutor. So perhaps inside the getSlotBasedExecutor where OpDebug info is set (this will ultimately go into <db>.system.profile after the operation is done), we can add setting a flag on CurOp. I'm unfamiliar with if there are any nesting problems to worry about, e.g. the DBDirectClient and leaving CurOp flags set when no longer running a query, or perhaps even subsequently running a query that uses the classic engine. Granted, that sounds like a problem for internal server operations, rather than user initiated operations. I'm not sure what the status quo is for this type of thing. |
| Comments |
| Comment by Chris Harris [ 06/Jan/23 ] |
|
The currentOp command is deprecated (not sure why that's not reflected in the doc?). It has been replaced by the $currentOp aggregation stage which is NOT deprecated. Output between the two operations are similar (if not identical?) and the helper function has been updated to automatically use the right one. This ticket is still needed |
| Comment by Sarah Olson [ 07/Dec/22 ] |
|
christopher.harris@mongodb.com, We thought currentOp was going to be deprecated. Is this ticket still necessary? |
| Comment by Education Bot [ 15/Nov/22 ] |
|
Fix Version updated for upstream |