Buy Percona ServicesBuy Now!

Testing Samsung storage in tpcc-mysql benchmark of Percona Server

 | July 26, 2016 |  Posted In: Benchmarks, MySQL


This blog post will detail the results of Samsung storage in tpcc-mysql benchmark using Percona Server.

I had an opportunity to test different Samsung storage devices under tpcc-mysql benchmark powered by Percona Server 5.7. You can find a summary with details here

I have in my possession:

  • Samsung 850 Pro, 2TB: This is a SATA device and is positioned as consumer-oriented, something that you would use in a high-end user desktop. As of this post, I estimate the price of this device as around $430/TB.
  • Samsung SM8631.92TB: this device is also a SATA, and positioned for a server usage. The current price is about $600/TB. 
  • Samsung PM1725, 800GB: This is an NVMe device, in a 2.5″ form factor, but it requires a connection to a PCIe slot, which I had to allocate in my server. The device is high-end, oriented for server-side and demanding workloads. The current price is about $1300/TB.

I am going to use 1000 warehouses in the  tpcc-mysql benchmarks, which corresponds roughly to a data size of 100GB.

This benchmark varies the innodb_buffer_pool_size from 5GB to 115GB. With 5GB buffer pool size only a very small portion of data fits into memory, which results in intensive foreground IO reads and intensive background IO writes. With 115GB almost all data fits into memory, which results in very small (or almost zero) IO reads and moderate background IO writes.

All buffer pool sizes in the middle of the interval correspond to resulting IO reads and writes. For example, we can see the read to write ratio on the chart below (received for the PM1725 device) with different buffer pool sizes:

tpcc-mysql benchmarks

We can see that for the 5GB buffer pool size we have 56000 read IOPs operations and 32000 write IOPs. For 115GB, the reads are minimal at about 300 IOPS and the background writes are at the 20000 IOPs level. Reads gradually decline with the increasing buffer pool size.

The charts are generated with the Percona Monitoring and Management tools.


Let’s review the results. The first chart shows measurements taken every one second, allowing us to see the trends and stalls.

tpcc-mysql benchmarks

If we take averages, the results are:

tpcc-mysql benchmarks

In table form (the results are in new order transactions per minute (NOTPM)):

bp, GB pm1725 sam850 sam863 pm1725 / sam863 pm1725 / sam850
5 42427.57 1931.54 14709.69 2.88 21.97
15 78991.67 2750.85 31655.18 2.50 28.72
25 108077.56 5156.72 56777.82 1.90 20.96
35 122582.17 8986.15 93828.48 1.31 13.64
45 127828.82 12136.51 123979.99 1.03 10.53
55 130724.59 19547.81 127971.30 1.02 6.69
65 131901.38 27653.94 131020.07 1.01 4.77
75 133184.70 38210.94 131410.40 1.01 3.49
85 133058.50 39669.90 131657.16 1.01 3.35
95 133553.49 39519.18 132882.29 1.01 3.38
105 134021.26 39631.03 132126.29 1.01 3.38
115 134037.09 39469.34 132683.55 1.01 3.40


The Samsung 850 obviously can’t keep with the more advanced SM863 and PM1725. The PM1725 shows a greater benefit with smaller buffer pool sizes. In cases using large amounts of memory, there is practically no difference with SM863. The reason is that with big buffer pool sizes, MySQL does not push IO subsystem much to use all the PM1725 performance.

For the reference, my.cnf file is

Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.


  • Vadim,

    Great results. Interesting to see in these test when you become write bound (higher buffer pool sizes) you can get by with relatively slower storage (sam863) while when very intensive reads required pm1725 shines.

    I wonder are all of these storage solutions good enough in terms of durability, in terms of retaining acknowledged data in case of power off ? This might be more critical than raw performance for databases.

    It also looks like you used only 10-20% of storage for the test, which can impact especially write performance significantly. You did not test this did you ? Sysbench fileIO can be easy to validate this.

Leave a Reply