[SERVER-16482] Decreased throughput due to changes in scheduling algorithm? (mms-prod-pings1) Created: 09/Dec/14  Updated: 25/Jan/15  Resolved: 05/Jan/15

Status: Closed
Project: Core Server
Component/s: Performance
Affects Version/s: 2.8.0-rc2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Cailin Nelson Assignee: Kaloian Manassiev
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File server16482_queries_per_second.png     PNG File server16482_worse_case_latencies.png     PNG File throughput.png     PNG File updates.png    
Issue Links:
Duplicate
duplicates SERVER-16065 Long flush pauses in MMAPv1 Closed
Related
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Please see attached MMS graph showing a time range that shows a particular workload on 2.6.3 and then 2.8.0rc2 (mmapv1). Note that the query opcounters (bright green, highest line) and the update opcounters (lighter green, lower line) both decreased when we upgrade to 2.8.0rc2.

One significant workload on this replica set has the following hourly pattern:

  • 0-20: "rest"
  • 20-40: do as much work as possible. Lots of updates and reads.
  • 0: bail, even if not done

You can see the change a bit more clearly in this 5 minute average of just update opcounters:



 Comments   
Comment by Cailin Nelson [ 25/Jan/15 ]

We are pleased to confirm that, as of 3.0.0-rc6, we now have increased throughput on the newest version of MongoDB!

Comment by Kaloian Manassiev [ 05/Jan/15 ]

Resolving as potential duplicate of SERVER-16065. Once we add the early lock release logic, we will reevaluate.

Comment by Kaloian Manassiev [ 18/Dec/14 ]

This might be remotely related to SERVER-16065. In 2.8 we do remap more frequently (which can be optimized) and this might be causing writes to be stalled more than in 2.6, where 66% (2/3) of the time we would the locks immediately after the diffs have been collected with the actual compression and I/O happening outside of a lock.

Comment by Githook User [ 10/Dec/14 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-16482 Do not look further in the conflict queue if X lock was just granted

This is a small optimization, which would help with the LM cost in the
presence of X-lock conflicts, such as the MMAP V1 collection lock.
Branch: master
https://github.com/mongodb/mongo/commit/5b44e4b489ef6a8eca4e48d3124665f404cc2c92

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