-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.0.2
-
Component/s: WiredTiger
-
ALL
-
(copied to CRM)
- YCSB 30M documents, 10 fields, ~1kB/document, total ~30GB
- 50/50 read/update workload
- 40 GB cache, 128 GB memory, 32 CPUs
- slow SSD disk (~80-100 MB/s)
- no journal (to simplify the situation)
- per mongostat, cache is at 100% utilization, 80% dirty pretty much throughout the test.
During each checkpoint two calls to fdatasync are made. Because this scenario is i/o constrained the fdatasyncs take a substantial amount of time, and during both fdatasync calls throughput falls to exactly 0 for the duration of the fdatasync. This is seen in A-B, C-D, E-F, G-H, I-J, K-L below.
In many, but not all, such cases WT bumps the "eviction server unable to reach goal" counter.
Similar test with a larger cache (the default 64GB) does not show this issue.
Note: this is the same test as reported in SERVER-18315; opening two separate tickets to track what may be separate issues.
- depends on
-
WT-1941 Sync the journal directory, not its parent
- Closed
- is related to
-
SERVER-18315 Throughput drop during transaction pinned phase of checkpoints under WiredTiger
- Closed
-
SERVER-22606 Startup warning if ext4 is used with WiredTiger
- Closed
- related to
-
SERVER-18629 WiredTiger journal system syncs wrong directory
- Closed
-
SERVER-18674 Very low throughput during portion of checkpoint under WiredTiger
- Closed