Checkpoint performance

What is this page

A common problem with high throughput key/value stores is that throughput can stall when creating a database checkpoint. WiredTiger engineering has put a lot of effort into avoiding this problem.

Measurement setup

We are using the WiredTiger wtperf benchmark program to generate results. The program is included in WiredTiger release packages (and on Git). The source code is at bench/wtperf/wtperf.c

I'm using an AWS High I/O instance type to do measurements. Specifications as follows:

• 60.5 GiB of memory
• 35 EC2 Compute Units (16 virtual cores*)
• 2 SSD-based volumes each with 1024 GB of instance storage
• 64-bit platform
• I/O Performance: Very High (10 Gigabit Ethernet)
• Storage I/O Performance: Very High**
• API name: hi1.4xlarge

The two SSD drives are configured with RAID0 and XFS.

Benchmark configuration file:

# wtperf options file: btree with inserts/updates and checkpointing
conn_config="cache_size=1G"
table_config="type=file"
create=false
icount=50000000
report_interval=2
key_sz=10
checkpoint_threads=1
checkpoint_interval=100
run_time=900
sample_interval=5
threads=((count=1,reads=1),(count=1,updates=1))

A summary of the configuration:

• Using a WiredTiger btree table database type.
• Starting with 50 million string key/value pairs. Keys are 10 bytes, values are 100 bytes. Generating around 12GB of data.
• The load phase is not measured or reported in the results. Each run is started with the same initial database.
• 1 GB cache size - much smaller than the working set size.

Throughput

Using WiredTiger 2.3.1 release

Using WiredTiger from December 2012

Analysis

The graph formats are different, but it can be seen that the more recent version has approximately twice the throughput as the earlier code, and the throughput dropouts are no longer present.