[SERVER-16671] logging write conflicts at log level 0 is too aggressive Created: 26/Dec/14  Updated: 30/Jan/15  Resolved: 07/Jan/15

Status: Closed
Project: Core Server
Component/s: Logging, Storage
Affects Version/s: 2.8.0-rc4
Fix Version/s: 2.8.0-rc5

Type: Bug Priority: Major - P3
Reporter: Asya Kamsky Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Tested
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Since write conflicts are normal in multi-threaded workload that heavily updates same documents (ex: YCSB with latest or zipf distribution), the logging of it should be significantly lower.

Recommendation:

  • LogLevel 0: log nothing (updates with a lot of writeConflicts will be logged as slow ops if they exceed slowMS threshold)
  • LogLevel 1: log update conflicts > 100 attempts
  • LogLevel 2: log update conflicts > 10 attempts
  • LogLevel 3+ : keep at current logging or log all.


 Comments   
Comment by Githook User [ 08/Jan/15 ]

Author:

{u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}

Message: SERVER-16671: fit attempt rollover, sync6 failure
and check for interrupt in multi update with conflicts
Branch: master
https://github.com/mongodb/mongo/commit/1913b3148ce0a60b51c82f4f1fe5db7f6766a6c7

Comment by Githook User [ 07/Jan/15 ]

Author:

{u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}

Message: SERVER-16671: yielding portability
Branch: master
https://github.com/mongodb/mongo/commit/68da73df17d5a26bcc1151013ee5298b2c7df909

Comment by Githook User [ 07/Jan/15 ]

Author:

{u'username': u'erh', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}

Message: SERVER-16671: remove logging for write conflict at 0, add counter, fix pause
Branch: master
https://github.com/mongodb/mongo/commit/6fcf84b2716e5b883ee521113bf940546bfe1872

Generated at Thu Feb 08 03:41:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.