[SERVER-18315] Throughput drop during transaction pinned phase of checkpoints under WiredTiger Created: 04/May/15  Updated: 22/Jun/15  Resolved: 26/May/15

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: 3.0.2
Fix Version/s: 3.0.4, 3.1.3

Type: Bug Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Michael Cahill (Inactive)
Resolution: Done Votes: 0
Labels: FT, wttt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File try-13.png     PNG File try-15-gdb.png     PNG File try-15.png     PNG File try-23.png     PNG File try-25.png    
Issue Links:
Related
related to SERVER-18314 Stall during fdatasync phase of check... Closed
related to SERVER-18677 Throughput drop during transaction pi... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Participants:

 Description   
  • 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 while a transaction id is pinned for the checkpoint throughput falls by an order of magnitude (but not to 0). This is accompanied by activity in the "checkpoint blocked eviction" counter. This is seen in B-C, F-G, J-K below:

Similar test with a larger cache (the default 64GB) also shows this issue.

Note: this is the same test as reported in SERVER-18314; opening two separate tickets to track what may be separate issues.



 Comments   
Comment by Michael Cahill (Inactive) [ 26/May/15 ]

This fix has been backported, here: https://github.com/wiredtiger/wiredtiger/commit/bf0408ec3310f5a81746169cb12781c931866bd1

It will be in MongoDB 3.0.4.

Generated at Thu Feb 08 03:47:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.