[SERVER-81796] Reuse a single OperationContext in JournalFlusher Created: 03/Oct/23  Updated: 24/Jan/24  Resolved: 21/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Mathias Stearn Assignee: Chenhao Qu
Resolution: Fixed Votes: 0
Labels: perf-8.0, perf-tiger, perf-tiger-handoff, perf-tiger-poc, perf-tiger-q4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes SERVER-83579 Data race for setup the opCtx in flus... Closed
Related
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2023-11-27
Participants:
Linked BF Score: 162

 Description   

Right now the JournalFlusher thread [destroys and recreates](https://github.com/mongodb/mongo/blob/1501ee35cbe0fba60ecf1d77faa15bc6021a5551/src/mongo/db/storage/control/journal_flusher.cpp#L132-L134) its OperationContext on each iteration of the loop. This isn't a cheap operation, and it isn't necessary. We should instead remove that code and make sure that we release the snapshot prior to sleeping in each iteration. We will also need to be careful not to reuse the OpCtx after it is interrupted.

This isn't the biggest bottleneck in the j:1 latency, but because there is only one thread doing the loop, and this currently happens after we are notified that someone is waiting for journaling, it does contibute to j:1 latency. And its relative impact will grow as we address other bottlenecks.



 Comments   
Comment by Githook User [ 21/Nov/23 ]

Author:

{'name': 'Chenhao Qu', 'email': 'chenhao.qu@mongodb.com', 'username': 'quchenhao'}

Message: SERVER-81796 Reuse a single OperationContext in JournalFlusher
Branch: master
https://github.com/mongodb/mongo/commit/8dcce7dd33f781d898dbbdeada87cb3cad22664c

Generated at Thu Feb 08 06:47:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.