-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.0.23, 5.0.7
-
Component/s: None
-
Query Execution
-
ALL
-
Execution Team 2024-06-10, Execution Team 2024-06-24, Execution Team 2024-07-08, Execution Team 2024-07-22
When modify one single document concurrently, only on request can commit successfully, and other requests get WriteConflictExceptions and retry internally(https://github.com/mongodb/mongo/blob/v5.0/src/mongo/db/concurrency/write_conflict_exception.h#L70-L106).
logAndBackofff(https://github.com/mongodb/mongo/blob/v5.0/src/mongo/db/concurrency/write_conflict_exception.cpp#L51-L59) is called before each retry attempt, and sleep is called when numAttempts is greater than 3(https://github.com/mongodb/mongo/blob/v5.0/src/mongo/util/log_and_backoff.cpp#L39-L51)
But the resources of these requests are not released while sleeping, so here is the problem : newly incoming requests are stucked, because the global tickets and global/database/collection locks are held by a lot of "sleeping retry requests".
For example, if 128 write requests are sleeping for 10ms (and waiting to retry again) in the same time, then there are no available global write ticket during this 10ms. All newly incoming write requests are stucked, but MongoDB has nothing to do (and just sleep).
I think it is better to release all resources before sleep and get back resources after sleep if the retry-function is not in a WUOW. In this way, MongoDB can handle more requests in this period. My basic idea is this:
// release all resources Locker::LockSnapshot ls; invariant(opCtx->lockState()->saveLockStateAndUnlock(&ls)); // logAndBackoff sleep // get all resources back and retry opCtx->lockState()->restoreLockState(ls);
- is related to
-
SERVER-66750 Determine if lock acquisition can happen inside of the writeConflictRetry in write_ops_exec.cpp
- Closed
-
SERVER-66752 Determine if lock acquisition can happen inside of the writeConflictRetry in find_and_modify.cpp
- Closed
-
SERVER-66751 Upsert stage should use generic yield machinery instead of writeConflictRetry
- Needs Scheduling
- related to
-
SERVER-88000 Implement real exponential backoff and jitter in write conflict retry
- Closed