-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Execution Team 2021-01-25, Repl 2021-03-08, Repl 2021-03-22, Repl 2021-04-05, Repl 2022-03-21, Repl 2022-04-04, Repl 2022-04-18, Repl 2022-05-02, Repl 2022-05-16, Repl 2022-05-30, Repl 2022-06-13, Repl 2022-06-27
-
(copied to CRM)
A simple workload with a single thread doing updates as fast as possible sees the following:
- 4.2
- primary
- updates: 1200/s
- log flushes: 300/s
- secondary
- batches: 280/s
- log flushes: 300/s
- primary
- 4.4
- primary
- updates: 1250/s
- log flushes: 10/s; much improved in 4.4 due to PM-1274
- seccondary
- batches: 1200/s
- log flushes: 2400/s; much worse in 4.4 than 4.2, and much higher than primary
- primary
This creates a much higher i/o requirement on the secondary in 4.4, and much higher on the secondary than the primary.
Two possible issues:
- Do we need to flush more often on the secondary than the primary?
- Do we need to do 2 flushes per batch?
- depends on
-
SERVER-54938 Only flush journal once per batch on secondary oplog application
- Closed
-
SERVER-54939 Investigate secondary batching behavior in v4.4
- Closed
- duplicates
-
SERVER-54939 Investigate secondary batching behavior in v4.4
- Closed
- is related to
-
SERVER-25249 High I/O load in secondary nodes with WiredTiger engine (caused by journaling)
- Closed
-
SERVER-54938 Only flush journal once per batch on secondary oplog application
- Closed
-
SERVER-65723 Add tunable parameter to improve batching on secondaries
- Closed
- related to
-
SERVER-59776 50% regression in single multi-update
- Closed