-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
QO 2023-07-24, QO 2023-08-07
I ran an experiment or two to see what the impact was on regular traffic when $queryStats is run and it seems we have an opportunity to reduce the impact (aside from already-filed SERVER-77567).
I noticed that we acquire the lock for a single partition at a time, but then we go through and compute the hmac-transformed key for each entry still while holding the lock. This should not be necessary, but will take some care to get right.
Here is where we do the hmac-intensive work: https://github.com/10gen/mongo/blob/505d34325477993864f4c8ead7878dda662ed9d5/src/mongo/db/pipeline/document_source_query_stats.cpp#L177
You can see it is within scope of the 'onePartition' locked object, preventing any progress for queries which would need to record metrics in that partition.
I think what should be done is:
- Reduce the critical section to only acquire the things we need to do our computations. Namely, rather than producing a vector of Document result objects during the critical section, only collect shared_ptr<QueryStatsEntry>}}s and {{metrics->toBSON() while holding the lock.
- Make sure we don't have race conditions by:
- using shared_ptr to ensure the QueryStatsEntrys do not get evicted and freed out from under us
- Make QueryStatsEntry::keyGenerator be const to prove/enforce that there will not be any data races between ongoing metric recording and us calling 'computeQueryStatsKey()' - which we will now do outside of the lock.
- is depended on by
-
SERVER-85064 Tracking: M0 performance improvement ideas
- Closed