3

I am experiencing ALOT of this WriteConflictException in my mongo log file, this does not seem to affect the application, because I am not seeing any special errors and everything seems to work fine.

Should I be concerned about this?

> <Time> D WRITE    [conn1397953] Caught
> WriteConflictException doing plan execution on ***, attempt: 1
> retrying 2018-11-20T06:35:39.612+0000 D WRITE    [conn1397956] Caught
> WriteConflictException doing plan execution on ***, attempt: 1
> retrying 2018-11-20T06:35:40.149+0000 D WRITE    [conn961669] Caught
> WriteConflictException doing plan execution on ***,
> attempt: 1 retrying 2018-11-20T06:35:40.149+0000 D WRITE   
> [conn961669] Caught WriteConflictException doing findAndModify on
> ***, attempt: 0 retrying

Thanks

0

this does not seem to affect the application, because I am not seeing any special errors and everything seems to work fine.

Write conflict exceptions (WCEs) are an indication from the WiredTiger storage engine that multiple internal writers are trying to update the same data. WiredTiger uses optimistic concurrency control (more specifically Multi-Version Concurrency Control aka MVCC) rather than pessimistic (or lock-based) document updates.

WCEs are an expected (and mostly internal) aspect of this approach: when the storage engine detects conflicts between two concurrent write operations, one will incur a write conflict and be transparently retried. The WCEs are logged for diagnostic purposes but are not exceptions that your application needs to handle.

Should I be concerned about this?

A small number of write conflict exceptions can be expected and should not have any impact aside from some possible (and generally negligible) latency for internal retries. Your redacted log lines show low retries and do not appear to be concerning in terms of WCEs.

If you are seeing updates with tens or hundreds of write conflict exceptions (or significantly slow execution), it would be worth reviewing the data model and updates in question for potential improvements in efficiency. For example, if a high number of write conflicts was being logged when incrementing a counter in a popular document, you might consider coalescing N updates of {$inc: 1} into a single update of {$inc: N}.

The MongoDB Concurrency FAQ is also worth reviewing for more information.

  • "If you are seeing updates with tens or hundreds of write conflict exceptions", My log file is filled with these all the time. not sure what constitutes as a lot. what I can say is that I do not see the "retry count" go over the single digit, it's mostly 0-5. – Gleeb Nov 25 '18 at 12:11
  • @Gleeb This sounds like an expected outcome for your data model and concurrent updates. I would not be overly concerned about individual updates with single digit WCE retries. WCEs are retried with a increasing delay (in milliseconds): first 3 attempts are immediate, wait increases to 1 milli for the next 6 attempts, and then to 5 millis after 10 attempts. Getting into high double digits and beyond will start adding more appreciable latency and indicate a more problematic update pattern. – Stennie Nov 25 '18 at 23:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.