- Administration >
- MongoDB Performance >
- Database Profiler
Database Profiler¶
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.
This document outlines a number of key administration options for the database profiler. For additional related information, consider the following resources:
Profiling Levels¶
The following profiling levels are available:
Level | Description |
---|---|
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. |
Enable and Configure Database Profiling¶
You can enable database profiling from the mongo
shell or
through a driver using the profile
command. This section
will describe how to do so from the mongo
shell. See your driver documentation if you want to control the profiler from
within your application.
When you enable profiling, you also set the profiling level. 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, use the
db.setProfilingLevel()
helper in the mongo
shell,
passing the profiling level as a parameter.
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.
Specify the Threshold for Slow Operations¶
To change the slow operation threshold, specify the desired threshold value in one of the following ways:
- Set the value of
slowms
using theprofile
command ordb.setProfilingLevel()
shell helper method. - Set the value of
--slowms
from the command line at startup. - Set the value of
slowOpThresholdMs
in a configuration file.
By default, the slow operation threshold is 100 milliseconds. Databases
with a profiling level of 1
will profile operations slower than the
threshold.
For example, the following code sets the profiling level for the
current database to 1
and sets the slow operation threshold for the
mongod
instance to 20 milliseconds:
Important
The slow operation threshold applies to all databases in a
mongod
instance. It is used by both the database profiler
and the system log and should be set to the highest useful value to
avoid performance degradation.
For MongoDB 3.6 deployments, starting in version 3.6.11, 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.
Profile a Random Sample of Slow Operations¶
New in version 3.6.
To profile only a randomly sampled subset of all slow operations , specify the desired sample rate in one of the following ways: [1]
- Set the value of
sampleRate
using theprofile
command ordb.setProfilingLevel()
shell helper method. - Set the value of
--slowOpSampleRate
from the command line at startup. - Set the value of
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
current database to 1
and sets the profiler to sample 42% of all slow operations:
Important
The sample rate value applies to all databases in a
mongod
instance. It is used by both the database profiler
and the system log.
Important
When logLevel
is set to 0
, MongoDB records slow
operations to the diagnostic log at a rate determined by
slowOpSampleRate
. For MongoDB 3.6
deployments, starting in version 3.6.11, 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.
Check Profiling Level¶
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:
Enable Profiling for an Entire 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. [1]
The slowms
and slowOpSampleRate
also affect which operations
are recorded to the diagnostic log when logLevel
is
set to 0
.
See also
View Profiler Data¶
The database profiler logs information about database operations in the
system.profile
collection.
To view profiling information, query the system.profile
collection. You can use
$comment
to add data to the query document to make it
easier to analyze data from the profiler. To view example queries, see
Example Profiler Data Queries.
For an explanation of the output data, see Database Profiler Output.
Example Profiler Data Queries¶
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:
Profiler Overhead¶
When enabled, profiling has a minor effect on performance. 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.
Change Size of system.profile
Collection on the Primary¶
To change the size of the system.profile
collection, you must:
- Disable profiling.
- Drop the
system.profile
collection. - Create a new
system.profile
collection. - Re-enable profiling.
For example, to create a new system.profile
collections that’s 4000000
bytes, use
the following sequence of operations in the mongo
shell:
Change Size of 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.
[1] | (1, 2) For MongoDB 3.6 deployments, starting in version 3.6.11, 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. |