On this page本页内容
The database profiler collects detailed information about Database Commands executed against a running mongod
instance. This includes CRUD operations as well as configuration and administration commands. The profiler writes all the data it collects to the system.profile
collection, a capped collection in the admin
database. See Database Profiler Output for an overview of the system.profile
documents created by the profiler.
The profiler is off
by default. You can enable the profiler on a per-database or per-instance basis at one of several profiling levels.
When enabled, profiling has an effect on database performance and disk use. See Database Profiler Overhead for more information.
This document outlines a number of key administration options for the database profiler. For additional related information, consider the following resources:
The following profiling levels are available:
Level | |
---|---|
0 |
The profiler is off and does not collect any data. This is the default profiler level. |
1 |
The profiler collects data for operations that take longer than the value of slowms . |
2 |
The profiler collects data for all operations. |
You can enable database profiling for mongod
instances .
This section uses the mongo
shell helper db.setProfilingLevel()
helper to enable profiling. For instructions using the driver, see your driver documentation.
When you enable profiling for a mongod
instance, you set the profiling level to a value greater than 0. The profiler records data in the system.profile
collection. MongoDB creates the system.profile
collection in a database after you enable profiling for that database.
To enable profiling and set the profiling level, pass the profiling level to the db.setProfilingLevel()
helper. For example, to enable profiling for all database operations, consider the following operation in the mongo
shell:
The shell returns a document showing the previous level of profiling. The "ok" : 1
key-value pair indicates the operation succeeded:
To verify the new setting, see the Check Profiling Level section.
The slowms and sampleRate profiling settings are global. When set, these settings affect all databases in your process.
When set via the profile
command or db.setProfilingLevel()
shell helper method, profiling level and filter settings are set at the database
level. When set as either command line or configuration file options, profiling level and filter
settings affect the entire process.
By default, the slow operation threshold is 100 milliseconds. To change the slow operation threshold, specify the desired threshold value in one of the following ways:
slowms
using the profile
command or db.setProfilingLevel()
shell helper method.--slowms
from the command line at startup.slowOpThresholdMs
in a configuration file.For example, the following code sets the profiling level for the current mongod
instance to 1
and sets the slow operation threshold for the mongod
instance to 20 milliseconds:
Profiling level of 1
will profile operations slower than the threshold.
Important
The slow operation threshold applies to all databases in a mongod
instance. It is used by both the database profiler and the diagnostic log and should be set to the highest useful value to avoid performance degradation.
Starting in MongoDB 4.0, you can use db.setProfilingLevel()
to configure slowms
and sampleRate
for mongos
. For the mongos
, the slowms
and sampleRate
configuration settings only affect the diagnostic log and not the profiler since profiling is not available on mongos
. [1]
For example, the following sets a mongos
instance’s slow operation threshold for logging slow operations:
Starting in MongoDB 4.2, the profiler entries and the diagnostic log messages (i.e. mongod/mongos log messages) for read/write operations include:
queryHash
to help identify slow queries with the same query shape.planCacheKey
to provide more insight into the query plan cache for slow queries.Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages are logged for the secondaries in the diagnostic log
under the REPL
component with the text applied op: <oplog entry> took <num>ms
. These slow oplog entries depend only on the slow operation threshold. They do not depend on the log levels (either at the system or component level), or the profiling level, or the slow operation sample rate. The profiler does not capture slow oplog entries.
New in version 3.6.版本3.6中的新功能。
To profile only a randomly sampled subset of all slow operations , specify the desired sample rate in one of the following ways: [2]
sampleRate
using the profile
command or db.setProfilingLevel()
shell helper method.--slowOpSampleRate
for mongod
or --slowOpSampleRate
for mongos
from the command line at startup.slowOpSampleRate
in a configuration file.By default, sampleRate
is set to 1.0
, meaning all slow
operations are profiled. When sampleRate
is set between 0 and 1, databases with profiling level 1
will only profile a randomly sampled percentage of slow operations according to sampleRate
.
For example, the following method sets the profiling level for the mongod
to 1
and sets the profiler to sample 42% of all slow operations:
The modified sample rate value also applies to the system log.
Starting in MongoDB 4.0, you can use db.setProfilingLevel()
to configure slowms
and sampleRate
for mongos
. For the mongos
, the slowms
and sampleRate
configuration settings only affect the diagnostic log and not the profiler since profiling is not available on mongos
. [1]
For example, the following sets a mongos
instance’s sampling rate for logging slow operations:
Important
When logLevel
is set to 0
, MongoDB records slow
operations to the diagnostic log at a rate determined by slowOpSampleRate
. Starting in MongoDB 4.2, the secondaries of replica sets log all oplog entry messages that take longer than the slow operation threshold to apply regardless of the sample rate.
At higher logLevel
settings, all operations appear in the diagnostic log regardless of their latency with the following exception: the logging of slow oplog entry messages by the secondaries. The secondaries log only the slow oplog entries; increasing the logLevel
does not log all oplog entries.
:binary:`~bin.mongod` or :binary:`~bin.
mongos`
¶[1] | (1, 2) See Database Profiling and Sharding. |
New in version 4.4.2.
You can set a filter to control which operations are profiled and logged. You can set the profiling filter in one of the following ways:
filter
using the profile
command or db.setProfilingLevel()
shell helper method.filter
in a configuration file.For mongod
instances, the filter
affects both the diagnostic log and, if enabled, the profiler.
For mongos
instances, the filter
affects the diagnostic log only and not the profiler since profiling is not available on mongos
.
Note
When a profiling filter
is set, the slowms and sampleRate options do not affect the diagnostic log or the profiler.
For example, the following db.setProfilingLevel()
method sets for a mongod
instance:
2
,{ op: "query", millis: { $gt: 2000 } }
, which causes the profiler to only log query
operations that took longer than 2 seconds.To view the profiling level, issue the following from the mongo
shell:
The shell returns a document similar to the following:
The was
field indicates the current profiling level.
The slowms
field indicates operation time threshold, in milliseconds, beyond which operations are considered slow.
The sampleRate
field indicates the percentage of slow operations that should be profiled.
To return only the profiling level, use the db.getProfilingLevel()
helper in the mongo
shell as in the following:
mongod
Instance¶For development purposes in testing environments, you can enable database profiling for an entire mongod
instance. The profiling level applies to all databases provided by the mongod
instance.
To enable profiling for a mongod
instance, pass the following options to mongod
at startup.
Alternatively, you can specify operationProfiling in the configuration file.
This sets the profiling level to 1
, defines slow operations as those that last longer than 15
milliseconds, and specifies that only 50%
of slow operations should be profiled. [2]
The slowms
and slowOpSampleRate
also affect which operations are recorded to the diagnostic log when logLevel
is set to 0
. The slowms
and slowOpSampleRate
are also available to configure diagnostic logging for mongos
. [2]
See also参阅
You cannot enable profiling on a mongos
instance. To enable profiling in a sharded cluster, you must enable profiling for each mongod
instance in the cluster.
However, starting in MongoDB 4.0, you can set the --slowms
and slowOpSampleRate
on mongos
to configure the diagnostic log for slow operations.
The database profiler logs information about database operations in the system.profile
collection.
To view profiling information, query the system.profile
collection. To view example queries, see Example Profiler Data Queries. For an explanation of the output data, see Database Profiler Output.
Tip
You can use $comment
to add data to the query predicate to make it easier to analyze data from the profiler.
This section displays example queries to the system.profile
collection. For an explanation of the query output, see Database Profiler Output.
To return the most recent 10 log entries in the system.profile
collection, run a query similar to the following:
To return all operations except command operations ($cmd), run a query similar to the following:
To return operations for a particular collection, run a query similar to the following. This example returns operations in the mydb
database’s test
collection:
To return operations slower than 5
milliseconds, run a query similar to the following:
To return information from a certain time range, run a query similar to the following:
The following example looks at the time range, suppresses the user
field from the output to make it easier to read, and sorts the results by how long each operation took to run:
When enabled, profiling has an effect on database performance, especially when configured with a profiling level of 2, or when using a low threshold value with a profiling level of 1. Profiling also consumes disk space, as it logs to both the system.profile
collection and also the MongoDB logfile
. Carefully consider any performance and security implications before configuring and enabling the profiler on a production deployment.
system.profile
Collection¶The system.profile
collection is a capped collection with a default size of 1 megabyte. A collection of this size can typically store several thousand profile documents, but some applications may use more or less profiling data per operation. If you need to change the size of the system.profile
collection, follow the steps below.
system.profile
Collection on the Primary¶To change the size of the system.profile
collection on the primary, you must:
system.profile
collection.system.profile
collection.For example, to create a new system.profile
collection that is 4000000
bytes (4 MB), use the following sequence of operations in the mongo
shell:
system.profile
Collection on a Secondary¶To change the size of the system.profile
collection on a secondary, you must stop the secondary, run it as a standalone, and then perform the steps above. When done, restart the standalone as a member of the replica set. For more information, see Perform Maintenance on Replica Set Members.
[2] | (1, 2, 3) Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages are logged for the secondaries in the diagnostic log under the REPL component with the text applied op: <oplog entry> took <num>ms . These slow oplog entries depend only on the slow operation threshold. They do not depend on the log levels (either at the system or component level), or the profiling level, or the slow operation sample rate. The profiler does not capture slow oplog entries. |