[SERVER-64341] W:1 writes with j: false perform worse than j: true with high concurrency Created: 09/Mar/22  Updated: 06/Dec/22  Resolved: 15/Mar/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Daniel Gomez Ferro Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2022-03-09-09-58-30-640.png     PNG File image-2022-03-09-09-59-50-353.png     PNG File image-2022-03-09-10-01-04-937.png     PNG File screenshot-1.png    
Issue Links:
Duplicate
Problem/Incident
Related
is related to SERVER-55606 Majority writes with j: false perform... Open
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 33

 Description   

The parallel insert performance test has recently started performing better for {w:1, j:true} writes than for {w:1, j:false} in runs with high concurrency (256, 512 or 1024 threads)

1024 threads, green j:false, pink j:true:

512 threads, pink j:false, orange j:true

32 threads, pink j:false, cyan j:true (j:false better as expected)

BF-24296 is the BF ticket on the switch point around the 3rd of February, which links to TIG-3391, an update to the C++ driver.



 Comments   
Comment by Daniel Gomez Ferro [ 15/Mar/22 ]

No, it's not using clustered indexes as far as I can tell.

Comment by Judah Schvimer [ 15/Mar/22 ]

Is this workload using a clustered index? There are some clustered index code changes around there that look interesting.

Comment by Daniel Gomez Ferro [ 15/Mar/22 ]

judah.schvimer from this evergreen page you can set the Measurement filter to OperationThroughput and the Test filter to parallelinsert-1024.Insert_W1 (or 512, 256...)

Comment by Judah Schvimer [ 14/Mar/22 ]

daniel.gomezferro, how do I generate the above graph to look at the relevant commits around the change point?

Generated at Thu Feb 08 06:00:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.