[SERVER-17716] Correlate the parts of distributed ops in db.currentOp() output Created: 24/Mar/15 Updated: 06/Dec/22 Resolved: 08/Dec/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jon Rangel (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Won't Do | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
It would greatly help debugging of long running distributed operations in a sharded cluster (such as scatter-gather aggregation queries) if db.currentOp() grouped together the parts of the operation in a logical way. Currently the operations running on the shards are displayed in the db.currentOp() output returned from a mongos, but it is difficult to tie together all the operations that originated from a single client request. Provide a cluster-wide db.currentOp() that can be run from a mongos and clearly lists all running operations including all parts of the op that are distributed to the shards e.g. for a running aggregation op that is currently at the merge cursors stage, we should clearly see all parts of the op displayed together and hierarchically. i.e.
|
| Comments |
| Comment by Kaloian Manassiev [ 15/Nov/21 ] |
|
This seems more of an Explain-related kind of work, so assigning to Query Execution. |
| Comment by Antoine Hom [ 30/Oct/15 ] |
|
Hello, Is it possible to get an updated status on this ticket? We are running long aggregation queries and we sometimes need to either kill it when it is running or clean up an already failed one. To do this clean up programatically and correctly we need a way to tie all the ops together from the cursorid (or another information that we have in the client) then kill them. This ticket might get soon escalated by our management as our customers are pushing hard for this. Regards, |
| Comment by Andy Schwerin [ 30/Mar/15 ] |
|
Recursive tracking like this sounds helpful, but only for operations that last more than a few network roundtrips (such as aggregations). |