[SERVER-1794] make CurOp query's lifespan same as the op - so we can just keep a pointer Created: 14/Sep/10 Updated: 06/Dec/22 Resolved: 17/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Duplicate | Votes: | 23 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query
|
||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Description |
|
PRO: much faster Clean up duplicated data between CurOp and OpDebug or eliminate one |
| Comments |
| Comment by Tess Avitabile (Inactive) [ 17/Feb/17 ] |
|
We believe this work is being tracked by |
| Comment by Chad Kreimendahl [ 30/Jun/14 ] |
|
Is there a method to increase this from 256 bytes to something larger? We're trying to monitor slow queries and most of them that hit (> 50ms) are "too large" |
| Comment by Alan Cima [ 22/Jun/14 ] |
|
How about just showing the comment field if there is one? That should be straightforward. |
| Comment by David Barshow [ 20/Jun/14 ] |
|
Whats the status of this? Even a truncated string would be acceptable 99% of the time I would suspect |
| Comment by Eliot Horowitz (Inactive) [ 03/Jun/14 ] |
|
Austin - the query will execute normally, just the reporting won't be in place. |
| Comment by Austin Riendeau [ 02/Jun/14 ] |
|
When this occurs { $msg: "query not recording (too large)" }, does mongo just drop the record or does it finish it? |