-
Type:
Bug
-
Resolution: Incomplete
-
Priority:
Major - P3
-
None
-
Affects Version/s: 3.6.0
-
None
-
Replication
-
Storage 2017-11-13, Storage 2017-12-04, Storage 2018-01-29, Repl 2018-02-26, Repl 2018-03-12, Repl 2018-03-26
-
(copied to CRM)
-
0
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
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:
- 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
-