In this blog post, we’ll discuss how a small innodb_page_size can create a performance boost for SSD.
In my previous post Testing Samsung storage in tpcc-mysql benchmark of Percona Server I compared different Samsung devices. Most solid state drives (SSDs) use 4KiB as an internal page size, and the InnoDB default page size is 16KiB. I wondered how using a different innodb_page_size might affect the overall performance.
Fortunately, MySQL 5.7 comes with the option innodb_page_size, so you can set different InnoDB page sizes than the standard 16KiB. This option is still quite inconvenient to use, however. You can’t change innodb_page_size for the existing database. Instead, you need to create a brand new database with a different innodb_page_size and reload whole data set. This is a serious showstopper for production adoption. Specifying innodb_page_size for individual tables or indexes would be a welcome addition, and you could change it with a simple ALTER TABLE foo page_size=4k.
Anyway, this doesn’t stop us from using innodb_page_size=4k in the testing environment. Let’s see how it affects the results using the same conditions described in my previous post.
Again we see that the PM1725 outperforms the SM863 when we have a limited memory, and the result is almost equal when we have plenty of memory.
But what about innodb_page_size 4k vs 16k.?
Here is a direct comparison chart:
Tabular results (in NOTPM, more is better):
| Buffer Pool, GiB | pm1725_16k | pm1725_4k | sam850_16k | sam850_4k | sam863_16k | sam863_4k | pm1725 4k/16k |
|---|---|---|---|---|---|---|---|
| 5 | 42427.57 | 73287.07 | 1931.54 | 2682.29 | 14709.69 | 48841.04 | 1.73 |
| 15 | 78991.67 | 134466.86 | 2750.85 | 6587.72 | 31655.18 | 93880.36 | 1.70 |
| 25 | 108077.56 | 173988.05 | 5156.72 | 10817.23 | 56777.82 | 133215.30 | 1.61 |
| 35 | 122582.17 | 195116.80 | 8986.15 | 11922.59 | 93828.48 | 164281.55 | 1.59 |
| 45 | 127828.82 | 209513.65 | 12136.51 | 20316.91 | 123979.99 | 192215.27 | 1.64 |
| 55 | 130724.59 | 216793.99 | 19547.81 | 24476.74 | 127971.30 | 212647.97 | 1.66 |
| 65 | 131901.38 | 224729.32 | 27653.94 | 23989.01 | 131020.07 | 220569.86 | 1.70 |
| 75 | 133184.70 | 229089.61 | 38210.94 | 23457.18 | 131410.40 | 223103.07 | 1.72 |
| 85 | 133058.50 | 227588.18 | 39669.90 | 24400.27 | 131657.16 | 227295.54 | 1.71 |
| 95 | 133553.49 | 226241.41 | 39519.18 | 24327.22 | 132882.29 | 223963.99 | 1.69 |
| 105 | 134021.26 | 224831.81 | 39631.03 | 24273.07 | 132126.29 | 222796.25 | 1.68 |
| 115 | 134037.09 | 225632.80 | 39469.34 | 24073.36 | 132683.55 | 221446.90 | 1.68 |
It’s interesting to see that 4k pages help to improve the performance up to 70%, but only for the PM1725 and SM863. For the low-end Samsung 850 Pro, using a 4k innodb_page_size actually makes things worse when using a high amount of memory.
I think a 70% performance gain is too significant to ignore, even if manipulating innodb_page_size requires extra work. I think it is worthwhile to evaluate if using different innodb_page_size settings help a fast SSD under your workload.
And hopefully MySQL 8.0 makes it easier to use different page sizes!