[SERVER-13115] Delete operations should parse queries without holding locks, when possible. Created: 10/Mar/14  Updated: 11/Jul/16  Resolved: 12/Mar/14

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 2.6.0-rc1
Fix Version/s: 2.6.0-rc2

Type: Improvement Priority: Major - P3
Reporter: Andy Schwerin Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File SERVER-12878-249-writelock.png     PNG File SERVER-12878-rc1-writelock.png     PNG File canonicalization_lock.png     PNG File canonicalization_lock2.png    
Issue Links:
Related
is related to SERVER-12878 Aggregations that do not return curso... Closed
Participants:

 Description   

In SERVER-10159/SERVER-12380, the update paths were modified to parse queries outside the write lock, when possible. This improves concurrency among writes, and between reads and writes, by minimizing time spent with data locks held.

The same optimization could be applied to the delete path in a straightforward way. See the implementation of the UpdateExecutor and its use in the BatchWriteExecutor for example.



 Comments   
Comment by Githook User [ 12/Mar/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13115 add error codes
Branch: master
https://github.com/mongodb/mongo/commit/1da2d21ffe90db991715127bd4140bcc83abb98b

Comment by Githook User [ 12/Mar/14 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-13115 Create DeleteExecutor to facilitate unlocked query parsing in delete operations.

Follows the pattern of the UpdateExecutor. Applies the optimization to legacy
and command form deletes.
Branch: master
https://github.com/mongodb/mongo/commit/4b96cf10a83f1d34eb7264d0e42c343eae0da60b

Comment by Githook User [ 12/Mar/14 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-13115 Move isQueryIsolated() into QueryPlannerCommon.

This method is useful outside of the update code where it was originally
implemented, so this patch moves it to the utility class QueryPlannerCommon.
Branch: master
https://github.com/mongodb/mongo/commit/4ddba591cf7defc9aca5e9cab526e9c9a8941a95

Comment by Andy Schwerin [ 11/Mar/14 ]

I've revised this ticket to only focus on the delete path, from which the sysbench benchmark saw performance improvements. Applying the optimization meaningfully to the find path is less straightforward, because the power of the optimization comes in part from not generating a CanonicalQuery at all when it is unnecessary. That is not a simple change to the find path.

Comment by Andy Schwerin [ 10/Mar/14 ]

And what do you see for 2.4.9? There's a lot of variability per host, I've noticed.

Comment by Davide Italiano [ 10/Mar/14 ]

Just to play devil's advocate, I'm not completely sure moving out of the lock scope the canonicalization step for find operations will buy as a lot, at least not in the 'sysbench-like' workload proposed in SERVER-12878, and honestly I'm not completely sure it's worth the effort considering all the risks, for now. I ended up with a superhacky patch that accomplish that, and these are the results.

Canonicalization out of the lock scope:

 Min.   :246.2  
 1st Qu.:251.0  
 Median :255.2  
 Mean   :258.5  
 3rd Qu.:263.6  
 Max.   :288.4  

Canonicalization under lock scope

      
 Min.   :236.6  
 1st Qu.:240.7  
 Median :243.1  
 Mean   :245.1  
 3rd Qu.:246.3  
 Max.   :264.4  

Comment by Alvin Richards (Inactive) [ 10/Mar/14 ]

Attached is an analysis from the logs of running a workload on 2.4.9 and RC1. There is a clear difference in the duration of the lock during remove (the blue dots) in RC1, so this would support the case that the optimization in update could be relevant to remove as well.

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