[SERVER-30554] relax locking mode in applyOps when applying CRUD-only ops non-atomically Created: 08/Aug/17  Updated: 30/Oct/23  Resolved: 10/Aug/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.4.9, 3.5.12

Type: Improvement Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-29802 Non-atomic applyOps command should no... Closed
Backwards Compatibility: Fully Compatible
Backport Completed:
Sprint: Repl 2017-08-21
Participants:

 Description   

With SERVER-29802, we can run multiple applyOps on the same server concurrently if we use

{allowAtomic: false}

and apply only CRUD. In this mode, applyOps() uses MODE_X to lock the database before calling applyOperation_inlock(). This does not take advantage of storage engines that support document level concurrency.

This ticket proposes to relax the locking rules in applyOps() to use MODE_IX instead of MODE_X when applying CRUD-only workloads non-atomically.



 Comments   
Comment by Githook User [ 10/Aug/17 ]

Author:

{'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}

Message: SERVER-30554 relax locking mode in applyOps when applying CRUD-only ops non-atomically

This allows concurrent applyOps commands to update the same collection on storage
engines that support document level concurrency.

(cherry picked from commit bca3f70566991afa2dfb38dc06494b0f6f04fffa)
Branch: v3.4
https://github.com/mongodb/mongo/commit/b8eb96c3c9c2ad2e0c4520785ba49cb9830b1a21

Comment by Githook User [ 10/Aug/17 ]

Author:

{'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}

Message: SERVER-30554 add library for applyOps concurrent tests

(cherry picked from commit b871fce9d308271f95159900c0e41d435f31e5ab)
Branch: v3.4
https://github.com/mongodb/mongo/commit/271cf7c28c00ffb15442fab3e5b49edef5797b9b

Comment by Githook User [ 10/Aug/17 ]

Author:

{'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}

Message: SERVER-30554 relax locking mode in applyOps when applying CRUD-only ops non-atomically

This allows concurrent applyOps commands to update the same collection on storage
engines that support document level concurrency.
Branch: master
https://github.com/mongodb/mongo/commit/bca3f70566991afa2dfb38dc06494b0f6f04fffa

Comment by Githook User [ 09/Aug/17 ]

Author:

{'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}

Message: SERVER-30554 add library for applyOps concurrent tests
Branch: master
https://github.com/mongodb/mongo/commit/b871fce9d308271f95159900c0e41d435f31e5ab

Comment by Steve Briskin (Inactive) [ 09/Aug/17 ]

spencer, The deployments that tend to cause us the most issues tend to have one, maybe two, very active collections and those collections tend to be in the same DB. I'm sure DB and collection-level concurrency will help some cases, but I don't think it'll help the typical case that we struggle with.

Comment by Spencer Brody (Inactive) [ 08/Aug/17 ]

steve.briskin, what level of concurrency do you need out of applyOps for backup's use case? We currently have got it down to db-level concurrency (we'll take a db-level lock for the duration of the applyOps in the non-atomic form when applying crud ops). Is that sufficient? Would collection-level concurrency be sufficient? Or do you need true document-level concurrency? I'm not sure if just doing collection-level actually buys us anything over doing document-level, just want to understand the requirements. Thanks!

Comment by Spencer Brody (Inactive) [ 08/Aug/17 ]

Seems like it should be possible even if applying non-crud ops. In theory I don't think the applyOps command should need to do any locking in the non-atomic form since every sub-command or operation must already be doing its own locking.

Generated at Thu Feb 08 04:24:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.