Small innodb_page_size As a Performance Boost for SSD
In this blog post, we’ll discuss how a small innodb_page_size can create a performance boost for SSD.
Join the DZone community and get the full member experience.
Join For FreeIn 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!
Published at DZone with permission of Vadim Tkachenko, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments