-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
DB Integration & Observability
-
None
-
None
-
None
-
None
-
None
-
None
-
None
NEW Description:
See this comment below for more details.
We should consider updating the Partitioned class to use ObservableMutex so we can have the observability into mutex contention in the query stats mutexes.
Consumers of Partitioned (ai-generated, quickly validated, possible a use may have been missed):
- Query stats store (QueryStatsStore, a PartitionedCache): src/mongo/db/query/query_stats/query_stats.h
- Join plan cache (JoinPlanCacheStore, a PartitionedCache): src/mongo/db/query/plan_cache/join_plan_cache.h
- Cursor manager (CursorManager::_cursorMap, a Partitioned used directly): src/mongo/db/query/client_cursor/cursor_manager.h
- SBE plan cache (PlanCacheBase): src/mongo/db/query/plan_cache/sbe_plan_cache.cpp
- Classic plan cache (PlanCacheBase, one per collection): src/mongo/db/query/collection_query_info.cpp
OLD Description:
Filed after cloning SERVER-111657:
With the ObservableMutex feature enabled in SERVER-106634, we can now have greater observability into the cost of mutex contention. Please consider identifiing critical long-lived mutexes that could benefit from this feature and enabling them following this usage guide. This feature is already enabled for ServiceContext, ReplicationCoordinator, TransactionCoordinator, Grid, SessionManager, and ConnectionPool mutexes.
I think this makes sense for the query stats store metric. Particularly if we have changes in $queryStats traffic pattern from query shape insights or the like. Might also make sense within the rate limiting code.
- is related to
-
SERVER-106634 Enable tracking contention metrics
-
- Closed
-
- related to
-
SERVER-111657 Consider using ObservableMutex for Query Execution mutexes
-
- Open
-
-
SERVER-106634 Enable tracking contention metrics
-
- Closed
-