Database Profiler vs Query Profiler

Published reference · snapshot 2026-10-20 · skill atlas-diagnostics-expert/references/database-profiler-vs-query-profiler.md

Also known as: Query Profiler vs slow query log

↓ Facts as markdown all context files

Source-anchored research for Database Profiler vs Query Profiler. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

The Database Profiler is a mongod feature that records one document per profiled operation (CRUD plus configuration and administration commands) in system.profile, a capped collection in each profiled database. It is off by default (level 0). MongoDB creates system.profile in a database only after profiling is enabled for that database. (high confidence) [source]
$queryStats is the third alternative the manual names. It runs on the admin database as the first pipeline stage, returns runtime statistics for recorded queries, is enabled on Atlas M10+, and requires the queryStatsRead privilege (the clusterMonitor role includes it). MongoDB marks it unsupported and not guaranteed stable across releases. (medium confidence) (verified as of 2026-10-18) [source]
The database profiler is a mongod feature. At level 1 or 2 it writes one document per profiled operation into a capped system.profile collection in each profiled database. It is off by default (level 0). (high confidence) [source]

How it works

On Atlas, the Database Profiler is gated by cluster tier. db.setProfilingLevel() is not supported on M0 and Flex clusters. Atlas Infinite clusters support the profile command only when the profiler level is 0. Atlas Core clusters support all profiler levels. (high confidence) (verified as of 2026-10-14) [source]
Profiler levels: 0 is off (default); 1 profiles operations over slowms or matching a filter; 2 profiles all operations. At level 2 the profiler ignores user-provided slowms and filter. When a filter is set, slowms and sampleRate are not used for profiling. (high confidence) [source]
MongoDB's manual warns 'The database profiler can degrade MongoDB performance' and names the Atlas Query Profiler, Atlas Performance Advisor and the $queryStats stage as alternatives to try first. Overhead is greatest at level 2 or with a low slowms at level 1, and profiling also uses disk because it writes to both system.profile and the log file. Percona rates the profiler's database overhead 'Moderate-High' and its connection-pool impact 'High', against 'Minimal' for reading the log. (high confidence) [source]
The database profiler is not available on mongos, because mongos has no collection for profiler output. db.setProfilingLevel(0, {...}) on a mongos only sets slowms, sampleRate and filter for the diagnostic log. To profile a sharded cluster, enable profiling on each mongod. (high confidence) [source]
Percona PMM Query Analytics (QAN) for MongoDB has two query sources. The default profiler source reads each database's system.profile, so profiling must be enabled on every monitored database. The mongolog source reads mongod log files. It needs PMM 3.3.0 or later (released 2025-07-09) and MongoDB 5.0 or later, and you enable it with --query-source=mongolog when you register the service with pmm-admin. (high confidence) (verified as of 2026-07-30) [source]

Measurements and reference values

Documented triage workflows differ in form. Atlas: open Query Insights, Query Profiler tab; pick a metric (Operation Execution Time by default, Docs Examined:Returned ratio, Keys Examined, Num Yields, Response Length); click a scatterplot point, then 'View more details' for query shape, execution statistics, query log and suggestions. Self-managed: query system.profile with ordinary find() filters (for example by ns, millis or ts range), or run show profile for the five most recent operations of at least 1 ms. (medium confidence) [source]
Do not rely on system.profile for history. It is a capped collection with a default size of 1 MB (typically several thousand documents). Resizing means disabling profiling, dropping and recreating the collection (on a secondary: stop it, run it standalone, then rejoin). A level set with db.setProfilingLevel() does not persist and reverts to 0 or the configured value on restart. Percona rates profiler history 'Volatile' against 'Disk-persisted' for the log. (high confidence) [source]
system.profile is a capped collection with a default size of 1 MB, usually several thousand documents. To resize it on a primary: disable profiling, drop system.profile, create a new capped system.profile with the wanted size, and re-enable profiling. On a secondary, first stop it and run it as a standalone. (low confidence) [source]

Problems, failure modes and limitations

Changing the Database Profiler level does not change which slow queries the Atlas Query Profiler shows. The control they share is the slow-operation threshold: slowms and sampleRate set through db.setProfilingLevel() always drive the diagnostic log, and they drive the profiler too when the level is 1 or 2. At level 0 they affect only the diagnostic log. (high confidence) [source]
Because the Query Profiler is built from slow-query log lines (operations over slowms, sampled by slowOpSampleRate), it holds a subset of what a level-2 Database Profiler records, since level 2 collects data for all operations. A MongoDB staff reply (2023-01-12) states the Atlas Profiler 'captures a subset of the db.system.profile collection'. (medium confidence) [source]
Default slow-operation thresholds differ. Self-managed mongod uses a fixed slowms of 100 ms. Atlas by default manages a per-host threshold from the average operation execution time on that host. A project owner can opt out to a fixed 100 ms through the Atlas Administration API, and Atlas advises against going lower. Free and Flex clusters have the managed threshold disabled and cannot enable it. Clusters with MongoDB Search enabled do not support it. (high confidence) (verified as of 2026-10-20) [source]
slowms and sampleRate are global to the mongod process. Level and filter set through db.setProfilingLevel() or the profile command apply per database, while --profile or operationProfiling.mode apply to the whole process. Profiling cannot be enabled on mongos because it has no collections for the profiler to write to, so mongos accepts only level 0 and its slowms, sampleRate and filter shape only its diagnostic log. In a sharded cluster, enable profiling on each mongod. (high confidence) [source]
Ops Manager has its own Profiler that is log-based like the Atlas Query Profiler and is not the Database Profiler. It tails mongod slow-query logs, does not write to system.profile, and its project setting does not change whether the database profiler is enabled. It shows the most recent 10,000 operations or 10 MB of logs, whichever limit is reached first, with at most 10,000 chart points and up to five minutes of delay. Ops Manager 4.4 and later enable it by default. (low confidence) (verified as of 2026-10-14) [source]
Datadog Database Monitoring for MongoDB reads slow operations from system.profile when profiling is enabled at level 1 or 2, and otherwise falls back to the getLog command over slow-query logs. Datadog notes getLog returns only the 'most recent 1024 mongod events', so busy databases can lose slow queries. For Atlas, Datadog supports M10 and higher and does not support Serverless or shared M0, M2 and M5 clusters. (medium confidence) (verified as of 2026-10-20) [source]
Slow oplog application on secondaries is a coverage difference. Secondaries log oplog entries that take longer than the slow threshold to apply, under the REPL component as 'applied op: <oplog entry> took <num>ms'. This does not depend on the profiling level and is affected by slowOpSampleRate. The Database Profiler does not capture slow oplog entries. (medium confidence) [source]
Slow-query logging and the Database Profiler are independent. With the profiler off (level 0, or operationProfiling.mode: off) mongod still writes operations slower than slowms to the diagnostic log, and a filter also applies to that log. This log is the data path that Percona mongolog tails ('does NOT populate system.profile') and that the Atlas Query Profiler builds on. (high confidence) [source]
To limit Database Profiler cost, prefer level 1 with a higher slowms, a sampleRate below 1.0 (for example 0.42 profiles a random 42% of slow operations), or a filter such as { op: 'query', millis: { $gt: 2000 } }. Slow operations are judged on workingMillis, which excludes lock and flow-control waits. Since MongoDB 8.0 a filter can use workingMillis. (high confidence) [source]
Atlas exposes the Query Profiler's log data outside the UI: 'atlas performanceAdvisor slowQueryLogs list --processName <host:port> --projectId <id> -o json' returns log lines for slow queries that Performance Advisor and Query Profiler identified. It defaults to the last 24 hours, returns up to 20000 lines (--nLog), accepts --namespaces db.collection, and needs the Project Data Access Read/Write role. For exact unsampled counts, download the mongod logs. (high confidence) (verified as of 2026-10-14) [source]
Amazon DocumentDB uses 'profiler' for a different mechanism: a cluster-level feature set in a custom cluster parameter group (profiler; profiler_threshold_ms with range 50 to INT_MAX and default 100; profiler_sampling_rate 0.0 to 1.0 and default 1.0) that exports slow operations to CloudWatch Logs on a best-effort basis. It is disabled by default and logs only when the whole result set fits in one batch under 16 MB. The page does not mention system.profile. (low confidence) (verified as of 2026-10-20) [source]
Do not leave level 2 or a very low slowms on in production. The manual says the slow threshold 'should be set to the highest useful value to avoid performance degradation'. Percona advises level 1 'to lower the load'. AWS advises starting a DocumentDB profiler threshold near 500 ms because 50 ms can cause performance issues for high-throughput applications. (high confidence) [source]
Profile data can expose sensitive query content. system.profile stores the full command object (replaced by a $truncated summary above 50 KB) with user, client and appName. Atlas warns that Query Profiler data 'may include sensitive information including the content of database queries', and Ops Manager carries the same warning. (high confidence) [source]
The Query Profiler can stop updating during a log spike. If a cluster generates an extremely large quantity of log messages, Atlas may stop collecting and storing new logs for a period of time. The limit applies to the Performance Advisor, Query Insights and Access Tracking UIs; downloadable log files are always complete. A 2023 MongoDB staff reply warned that forcing level 2 with slowms 0 could trigger these rate limits and stop the Query Profiler showing slow operations for the rest of its 24-hour monitoring period. (high confidence) [source]
Some high-latency $lookup operations leave no slow-query log entry for the foreign collection, so they do not appear in the Query Profiler for that collection. This happens when the foreign-collection read is local to the same shard; latency metrics still increase. (low confidence) [source]
Atlas documentation gives two different time figures for the Query Profiler: Analyze Slow Queries says a sample of historical queries for 'up to the last seven days', while the Query Profiler page sets a default view of the last 24 hours. Neither page says whether seven days is storage retention. (medium confidence) (verified as of 2026-10-20) [source]
The Atlas Query Profiler is a separate feature from the database profiler. Atlas docs say it identifies slow queries from entries in the mongod logs, and Atlas shows them on the Query Insights page, Query Profiler tab. The manual's Query Performance page and the Atlas CLI and Admin API pages describe the same log-based source. (high confidence) [source]
The manual frames the Atlas Query Profiler as a macro view of application load (a scatterplot built from log data) and the database profiler as a micro view of slow queries in the current load. To find all slow queries within a period it lists both profilers. For queries running now it points to the $currentOp aggregation stage. (medium confidence) [source]
The database profiler and the diagnostic log share one set of controls. slowms (default 100 ms) and sampleRate (default 1.0) apply to both. A filter set on a mongod also applies to both, and while a filter is set, slowms and sampleRate are not used for profiling or for slow-query log lines. slowms and sampleRate are global to the mongod process. Level and filter set through the profile command or db.setProfilingLevel() are per database. (high confidence) [source]
At level 0 the profiler is off, but slowms, sampleRate and filter still decide which slow operations go to the diagnostic log. A filter can be set at level 0 so it only affects the log. The profile command page also says that at level 2 full logging is enabled on both the profiler and the diagnostic log. (high confidence) [source]
MongoDB compares slowms with workingMillis, the time MongoDB spends working on the operation. Lock waits and flow control do not count toward the slow threshold. (high confidence) [source]
Profiler entries and slow-query log lines both carry planCacheShapeHash and planCacheKey, so slow queries with the same plan-cache query shape can be grouped. From MongoDB 8.0 the old queryHash field is duplicated into planCacheShapeHash; queryHash is deprecated and a future version will remove it. MongoDB 8.0 also adds queryShapeHash to both outputs. (high confidence) (verified as of 2026-10-19) [source]
A system.profile document and a slow-query log line carry mostly the same diagnostics (ns, command, planSummary, keysExamined, docsExamined, nreturned, hasSortStage, locks, storage, cpuNanos on Linux). Some names differ: profile millis, numYield and responseLength appear in the log as durationMillis (plus workingMillis), numYields and reslen. The log line is structured JSON with msg 'Slow query' and id 51803, so jq filters such as select(.attr.workingMillis>=2000) work on it. (high confidence) [source]
Atlas sets its own slow-operation threshold from the average operation execution time (per mongod host, per the Query Profiler page; 'on your cluster' per the CLI page). This managed threshold is on by default for dedicated M10+ clusters. Opting out through the Atlas Administration API switches to a fixed 100 ms. Free and Flex clusters have the managed threshold off and cannot enable it. (high confidence) (verified as of 2026-10-14) [source]
The Atlas Admin API (GET /api/atlas/v2/groups/{groupId}/processes/{processId}/performanceAdvisor/slowQueryLogs) and the CLI (atlas performanceAdvisor slowQueryLogs list) return the log lines for slow queries that the Performance Advisor and Query Profiler identified. nLogs defaults to 20000 and its maximum is 20000. If you give neither duration nor since, the call returns the previous 24 hours. (high confidence) (verified as of 2026-10-14) [source]
Atlas states that the Performance Advisor does not negatively affect cluster performance and that the Query Profiler's seven-day sample comes without additional cost or performance overhead. The manual's Monitor Slow Queries page says both the Atlas Query Profiler and the database profiler can affect server performance and use disk space. (medium confidence) (verified as of 2026-10-14) [source]
If a cluster generates an extremely large quantity of log messages during an activity spike, Atlas may stop collecting and storing new logs for a period of time. This rate limit applies only to the Performance Advisor UI, the Query Insights UI and the Access Tracking UI. Downloadable log files are always complete. (medium confidence) (verified as of 2026-10-19) [source]
The Atlas Query Profiler excludes bulk operations from its sampling and analysis, including bulkWrite() and updateMany with multiple stmtIds. Do not use it to hunt slow bulk writes. (low confidence) (verified as of 2026-10-19) [source]
Some high-latency $lookup operations leave no slow-query log line for the foreign collection when the foreign read is a local read on the same shard. They raise Namespace Insights latency metrics and operation counts but add no Query Profiler entry for the foreign collection. (low confidence) (verified as of 2026-10-19) [source]
The database profiler can degrade performance, most at level 2 or at level 1 with a low slowms. It writes to both system.profile and the log file, so it also uses disk. The manual's warning tells readers to consider the Atlas Query Profiler, the Atlas Performance Advisor or the $queryStats aggregation stage first, and to set the slow threshold to the highest useful value. (high confidence) [source]
Secondaries log oplog entries that take longer than the slow threshold to apply. These lines go only to the diagnostic log (REPL component, text 'applied op: ... took Nms'). They do not depend on the profiling level or log level, slowOpSampleRate affects them, and the profiler never captures them. (high confidence) [source]
MongoDB 8.3 adds a slow in-progress query threshold (default 5000 ms). Set it with the slowinprogms option of db.setProfilingLevel(), mongod --defaultSlowInProgMS, or operationProfiling.slowOpInProgressThresholdMs. MongoDB logs a query at most once when it crosses the threshold, and the entry holds less information than a standard slow-query line. (high confidence) (verified as of 2026-10-14) [source]
The getLog command reads from an in-memory (RAM) cache, not the log file. It returns at most the 1024 most recent events and truncates any event longer than 1024 characters. MongoDB says it is not a replacement for the log file. Datadog's Agent falls back to getLog when profiling is off and warns that on busy databases some slow queries may not be captured. (high confidence) [source]
Datadog Database Monitoring for self-hosted MongoDB reads slow operations from system.profile when profiling is at level 1 or 2, and from the getLog command when profiling is off. It samples running operations through $currentOp and takes query metrics from $queryStats (MongoDB 8.0 or later, Agent 7.78 or later, collection off by default). The page puts the Agent's default cost under one percent of query execution time and CPU. (low confidence) (verified as of 2026-10-20) [source]
Amazon DocumentDB's 'profiler' is a cluster-parameter feature, not system.profile. The parameters are profiler (enabled or disabled, default disabled), profiler_threshold_ms (50 to INT_MAX, default 100) and profiler_sampling_rate (0.0 to 1.0, default 1.0). It exports slow operations to CloudWatch Logs under /aws/docdb/<cluster>/profiler. AWS advises starting at 500 ms because a 50 ms threshold can cause performance issues for high-throughput applications. (low confidence) (verified as of 2026-10-20) [source]
The DocumentDB profiler logs on a best-effort basis and only emits a record when the whole result set fits in one batch under 16 MB. Drivers often default to small batches, so AWS suggests a large batch size (for example 100k) to capture slow queries, at the cost of retrieving more results before the response. (low confidence) (verified as of 2026-10-20) [source]
The manual's recipe for finding slow queries with the database profiler: run db.setProfilingLevel(1, 100); query system.profile with a projection of command, millis, docsExamined, keysExamined and nreturned, sorted by ts descending; read keysExamined 0 as no index used and docsExamined far above nreturned as an ineffective index; run explain() on suspects; run db.setProfilingLevel(0) when done. (medium confidence) [source]
A 2023 MongoDB community-forum reply says db.setProfilingLevel(2, {slowms: 0}) makes the Atlas Query Profiler show every query, but it adds significant load and can hit rate limits that stop the Query Profiler from showing further slow operations for the rest of the 24-hour monitoring period. (low confidence) (verified as of 2023-01-12) [source]

Comparisons and alternatives

The Atlas Query Profiler is a separate tool, not a view over system.profile. It identifies slow queries from mongod log entries and appears on the Query Insights page, Query Profiler tab. The Atlas docs say so directly ('The Query Profiler differs from the Database Profiler'), and a MongoDB staff reply says it 'reads from the slow logs rather than from the system.profile collection'. (high confidence) [source]
To lower profiler cost while keeping it on: use level 1 instead of 2, raise slowms, set sampleRate below 1.0 to profile a random fraction of slow operations (for example 0.42), or set a filter such as { op: 'query', millis: { $gt: 2000 } }. From MongoDB 8.0 a filter can use workingMillis. Turn profiling off with db.setProfilingLevel(0) when the investigation ends. (high confidence) [source]
The Atlas Performance Advisor works from the slow query log. It cannot suggest indexes for databases that use the ctime timestamp format (set iso8601-utc or iso8601-local instead). When the logged pipeline has consecutive $match stages that coalesce, the query shape it shows can differ from the query you ran. (medium confidence) [source]

Facts and statements

The Atlas Query Profiler and Performance Advisor are marked 'Only available on M10+ clusters'. Atlas enables the Query Profiler by default. A Project Owner (or Organization Owner on the parent organization) turns Performance Advisor and Profiler off under Project Settings, Database Monitoring Tools. Viewing needs Project Read Only or Project Observability Viewer access. (high confidence) (verified as of 2026-10-20) [source]
Atlas describes its log-based tools as free of overhead: the Query Profiler lets you 'explore a sample of historical queries for up to the last seven days without additional cost or performance overhead', and the Performance Advisor 'doesn't negatively affect the performance of your Atlas clusters'. These are vendor statements; no measurement was found. (medium confidence) (verified as of 2026-10-20) [source]
Percona PMM Query Analytics offers two MongoDB query sources that mirror this split. The MongoDB Profiler (default) reads system.profile through continuous database connections, needs profiling enabled explicitly on each database, works with remote instances, does not support mongos, and keeps volatile history. The Diagnostic log source (mongolog) tails the mongod log with operationProfiling mode off, needs PMM 3.3.0 or newer and MongoDB 5.0+, supports mongos, and keeps disk-persisted history. (high confidence) (verified as of 2026-07-10) [source]
Query Profiler display limits on the current Atlas page: about 100,000 sampled logs at a time (all of them if 100,000 or fewer were recorded for the selected hosts and time range), at most 100,000 chart data points, a default view of the last 24 hours, and up to five minutes of delay. Operations are sampled with a bucketing algorithm, so a wider time range can show fewer sampled operations than a narrower one. Bulk operations (bulkWrite(), updateMany with multiple stmtIds) are excluded. (low confidence) (verified as of 2026-10-20) [source]
Queryable Encryption operations are absent from the profiler record. CRUD operations against encrypted collections are omitted from system.profile, and $queryStats also does not collect information for queries that use Queryable Encryption. (medium confidence) [source]
Atlas opens both the Query Profiler page and the Performance Advisor page with 'Only available on M10+ clusters'. (medium confidence) (verified as of 2026-10-19) [source]
Atlas enables the Query Profiler by default. A Project Owner (or the parent Organization Owner) turns it off under Project Settings, Database Monitoring Tools, by toggling 'Performance Advisor and Profiler' to Off. Viewing needs Project Read Only or Project Observability Viewer. (low confidence) (verified as of 2026-10-19) [source]
Profiling levels: 0 is off (default). 1 profiles operations slower than slowms or matching a filter. 2 profiles all operations. At level 2 the profiler ignores user-provided slowms and filter values. (high confidence) [source]
The Atlas docs say you can explore a sample of historical queries in the Query Profiler for up to the last seven days without additional cost or performance overhead. The Query Profiler view defaults to the last 24 hours. (medium confidence) (verified as of 2026-10-19) [source]
Query Profiler data limits per the Atlas docs: about 100,000 sampled logs at a time; at most 100,000 chart data points; a bucketing algorithm adjusts sample size to the time range, so a wider range can show fewer sampled operations; log data is processed in batches and can lag real time by up to five minutes. For exact, unsampled counts, download the mongod logs. (low confidence) (verified as of 2026-10-19) [source]
The Atlas Query Profiler shows operations across the whole cluster by default and can be filtered by host or by primary and secondary groups. It bins operations that share the same operation type, namespace, hasSort and usedIndex values and occur around the same timestamp. (low confidence) (verified as of 2026-10-19) [source]
Profiling can expose unencrypted query data in the system log. Atlas warns that Query Profiler data may include sensitive information, including query content. The manual adds that both profilers can expose query metadata around encrypted fields. Review security implications before enabling either one on production. (high confidence) [source]
db.setProfilingLevel() changes do not persist. After a restart the level reverts to 0, or to the value of operationProfiling.mode or --profile. Atlas says the same for Query Profiler settings changed this way: they reset to defaults after a node restart. Atlas also warns that changing the threshold with db.setProfilingLevel can affect performance and system log settings. (high confidence) [source]
The profile command takes a write lock on the affected database while it enables or disables the profiler. The lock is usually short, but it blocks other operations until the command finishes. (low confidence) [source]
Percona recommends the log-based mongolog source for production with 100 or more databases, connection-pool errors, or mongos routers. It needs only one database connection at startup (to find the log path), works where system.profile access is unavailable such as mongos, and may increase disk I/O. Percona keeps the profiler as the default for simple setups under 100 databases, remote instances and real-time collection. (high confidence) (verified as of 2026-07-30) [source]
Percona's comparison table rates the profiler source Moderate-High database overhead, High connection-pool impact, linear degradation as database count grows, volatile query history and no mongos support. It rates the log source Minimal overhead, Minimal connection-pool impact, constant scaling, disk-persisted history and mongos support, and calls mongolog's performance impact 'virtually zero'. (low confidence) (verified as of 2026-07-30) [source]
Percona's profiler setup example uses operationProfiling mode: all (profile level 2) with slowOpThresholdMs: 200 and rateLimit: 100. rateLimit works only on Percona Server for MongoDB. The page also shows db.setProfilingLevel(2, {slowms: 0}) per database, which lasts until restart, and advises level 1 to lower server load. (low confidence) (verified as of 2026-07-30) [source]
db.setProfilingLevel() is not supported on M0 and Flex clusters. On Atlas Infinite clusters the profile command supports only level 0, while Atlas Core clusters support all profiler levels. (low confidence) (verified as of 2026-10-14) [source]

Children

$queryStats aggregation stage
$queryStats and $currentOp as alternatives to the profiler (frontier, viability 4.35 / 5)
Amazon DocumentDB profiler (CloudWatch Logs)
Atlas Query Insights: Query Shape Insights and Namespace Insights (frontier, viability 3.85 / 5)
Atlas Query Shape Insights and Namespace Insights (frontier, viability 3.40 / 5)
Atlas Real-Time Performance Panel
Atlas managed slow operation threshold and Performance Advisor index suggestions (frontier, viability 3.67 / 5)
Ops Manager Profiler
Parsing the mongod slow-query log (id 51803, workingMillis, durationMillis) (frontier, viability 4.03 / 5)
Percona PMM mongolog query source (frontier, viability 2.73 / 5, below research gate)
Percona PMM mongolog versus profiler query source
mongod diagnostic log slow-query format and slowOpSampleRate (frontier, viability 4.00 / 5)
MongoDB Query Optimization Tooling: Compass Explain, Atlas Query Insights and Performance Advisor
Atlas Slow-Query Log and Performance Advisor Automation

Frontier under this node: $queryStats and $currentOp as alternatives to the profiler (4.35), Atlas Query Insights: Query Shape Insights and Namespace Insights (3.85), Atlas Query Shape Insights and Namespace Insights (3.40), Atlas managed slow operation threshold and Performance Advisor index suggestions (3.67), Parsing the mongod slow-query log (id 51803, workingMillis, durationMillis) (4.03), Percona PMM mongolog query source (2.73), mongod diagnostic log slow-query format and slowOpSampleRate (4.00)

← the whole tree · 3D view· how to read this page