[SERVER-21855] Certain commands are never captured in system profiler Created: 10/Dec/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Diagnostics |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Certain commands are never captured in the system profiler, regardless of the value of the global profiling level (as set by the --profile command line option) or the database profiling level (as set by the profile command). Reproduce with following script, which runs a number of commands and then scrapes system.profile to determine which were profiled.
See the following shell session, which runs the above script against a 3.2.0 mongod instance started with --profile 2 (which enables profiling for all operations). No commands run by the script are profiled (with the exception of the create command used in the test setup).
Many commands have been affected by this issue since they were first introduced, though some have regressed over time. The following is a partial list of the regressions introduced over the past few major releases:
|
| Comments |
| Comment by J Rassi [ 21/Mar/16 ] |
|
Note also that the eval command doesn't generate a profiler entry when run with the "nolock" option set, according to |
| Comment by J Rassi [ 14/Jan/16 ] |
|
milkie suggests updating our documentation to state that commands which do not acquire a database lock will not be profiled. This seems reasonable, to me. To fix most of the remaining commands, I'd recommend an approach like the following:
That leaves a couple of special cases, createIndexes and applyOps:
I suggest that we defer this work until progress on |
| Comment by J Rassi [ 10/Dec/15 ] |
|
This was discovered while investigating As of current master, commands (with the exception of the write commands) will only be profiled if they explicitly use one of the following objects from db_raii.h:
This is because operations are never profiled unless they generate a call to CurOp::raiseDbProfileLevel(). The only callers of raiseDbProfileLevel() are the write commands batch executor and CurOp::enter_inlock(), and the only callers of CurOp::enter_inlock() are the constructors for the above three RAII objects. |