serverStatus metrics.query.planCache counters
Parent: Replanning loops and replanReason · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for serverStatus metrics.query.planCache counters. 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.
How it works
- Monitor per-engine replanned deltas per unit time on each process; restart resets serverStatus statistics. This sampling method is an inference from counter semantics and restart behavior. (medium confidence) [source]
- Read db.serverStatus().metrics.query.planCache for plan-cache statistics. MongoDB reports separate classic and sbe engine subdocuments; observe both when investigating replanning across engine workloads. (medium confidence) [source]
- classic.replanned and sbe.replanned count query plans discarded and re-optimized. The feature was designed to expose replanning frequency for diagnostics because high replanning rates may accompany performance problems. (medium confidence) [source]
How-to and procedures
- Avoid copying the JusDB article's totalSizeOfPlanCacheEntriesInBytes example as the documented field name. The official planCache reference uses totalSizeEstimateBytes; JusDB also presents totalPlanCacheEntriesInvalidated, which is absent from the cited reference's planCache field list. (medium confidence) [source]
Problems, failure modes and limitations
- Operational inference: compare counter changes over an observation interval and correlate increasing replanned values with query-specific slow-log replanReason evidence before attributing an instance-wide rise to a particular query loop. Tencent recommends this correlation, while MongoDB describes the counter as a frequency diagnostic. (medium confidence) [source]
Comparisons and alternatives
- totalQueryShapes is an approximate cached-query-shape count, and totalSizeEstimateBytes measures plan-cache bytes. They describe cache occupancy rather than replanning events; the manual dates their grouping under planCache to 7.2 and names the older query.planCacheTotalQueryShapes and query.planCacheTotalSizeEstimateBytes paths. (high confidence) [source]
Facts and statements
- Inspect db.serverStatus().metrics.query.planCache; classic and sbe expose separate hits, misses and replanned counters. hits measures cached-plan reuse; misses measures absence followed by planning. (high confidence) [source]
- The engine-specific replanned counters count discarded cached plans that undergo re-optimization. They are distinct from misses, which can occur without a previously cached plan. (high confidence) [source]
- MongoDB documents classic.replanned and sbe.replanned as new in 8.0 and also available in 7.0.22; dashboards must check the deployed patch version before expecting these fields. (low confidence) (verified as of 2026-10-30) [source]
- classic.skipped and sbe.skipped distinguish cache-ineligible queries from ordinary cache misses. MongoDB documents these fields as new in 7.3; SERVER-75678 lists 7.3.0-rc0 and explicitly motivates separating ineligible queries from absent cache entries. (high confidence) (verified as of 2024-01-19) [source]
- MongoDB 8.2 adds classic.replanned_plan_is_cached_plan and sbe.replanned_plan_is_cached_plan for replanning that produces an identical cached plan. Replanning therefore does not establish index switching. (low confidence) (verified as of 2026-10-30) [source]
- The JusDB monitoring example names totalSizeOfPlanCacheEntriesInBytes; MongoDB documentation and the relocation ticket instead name totalSizeEstimateBytes. Verify actual server output before adopting that example. (medium confidence) [source]
- SERVER-127703 records migration of PlanCache counters to OpenTelemetry metrics with fix version 9.0.0-rc0; the ticket alone does not establish availability in a deployed stable release. (low confidence) (verified as of 2026-10-23) [source]
- Within each engine subdocument, hits counts query plans found in cache and reused to avoid planning; misses counts plans absent from cache that went through planning. A miss is not the same event definition as discarded-plan re-optimization. (medium confidence) [source]
- Do not assume every 8.0 patch exposes replanned. Although the manual labels the counters new in 8.0 and also available in 7.0.22, SERVER-87572 lists fix versions 8.1.0-rc0, 8.0.5, and 7.0.22. Check the deployed patch before treating an absent field as zero. (medium confidence) (verified as of 2025-06-12) [source]
- MongoDB 8.2 adds classic.replanned_plan_is_cached_plan and sbe.replanned_plan_is_cached_plan. They count replanning operations that produce a plan identical to one already in cache; SERVER-98987 describes this as wasteful replanning and lists 8.2.0-rc0. (medium confidence) (verified as of 2026-03-09) [source]
- A rising replanned counter does not prove an index switch: replanning can choose the same plan again. Treat the count as evidence of replanning work, and use the same-plan counters where available to distinguish that outcome. (medium confidence) [source]
Children
- No children recorded.