Details
Description
Simple insert workload:
res = benchRun({
|
ops: [
|
{op: "insert", doc: {}, ns: "test.c"},
|
],
|
seconds: 45,
|
parallel: 15
|
})
|
printjson(res)
|
standalone shows ~11% throughput reduction
3.4.9: "totalOps/s" : 312257.31243007537,
|
3.6.0-rc0 "totalOps/s" : 277214.2306740861,
|
1-node replica set shows ~50% throughput reduction
3.4.9: "totalOps/s" : 181808.21357151057,
|
3.6.0-rc0 "totalOps/s" : 91202.31599375796,
|
Metrics for the 1-node replica set case suggest issue may be related to large number of write-lock calls, about 3 per insert:
Attachments
Issue Links
- depends on
-
SERVER-31902 Reduce contention on ShardingState::_mutex for insert workloads
-
- Closed
-
-
SERVER-31879 remove extraneous synchronization in oplog
-
- Closed
-
-
SERVER-31882 For vectored inserts, start transaction prior to assigning first timestamp
-
- Closed
-
-
SERVER-31899 Improve getTerm() performance
-
- Closed
-
-
SERVER-31912 waitUntilDurable() should use its own WT_SESSION, not one from the cache
-
- Closed
-
- related to
-
SERVER-34604 low performance under 3.6.4 with wiredTiger storage
-
- Closed
-
-
SERVER-40250 High contention for ReplicationCoordinatorImpl::_mutex in w:majority workloads
-
- Closed
-
-
SERVER-59776 50% regression in single multi-update
-
- Closed
-
-
SERVER-34562 I use YCSB testing comparise mongodb3.6.3 with mongodb3.4.13 ,find the mongodb3.4.13 insert and update performance is one and a half times than mongodb3.6.3
-
- Closed
-