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.

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.

performance boost for SSD

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:

performance boost for SSD

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!

Share this post

Comments (11)

  • Mark Callaghan

    How many clients did you use for these tests? (c=???)

    4k page size with 2X compression might not be efficient when storage sectors are 4k.

    August 10, 2016 at 8:34 pm
    • Vadim Tkachenko


      I’ve used 100 clients for these tests.

      August 10, 2016 at 8:52 pm
  • Fadi El-Eter (itoctopus)

    Hi Vadim,

    The test results are very interesting. A 70% increase in performance (even 20% for that simple change) is not bad.

    Most of our clients are with the same host – and they use Crucial SSDs. Do you have any idea whether Crucial SSDs will perform better on a lower innodb page size?

    Another quick question: If we change the page size, will copying an existing database (using phpMyAdmin, for example) to a new database do the trick for the new database to use the new page size?

    August 10, 2016 at 10:46 pm
    • Vadim Tkachenko

      I would put Crucial SSD on the same level as Samsung 850 Pro, so the benefit, as you can see from the data, may not be obvious.

      Copying data via mysqldump should work and will use new innodb_page_size.

      August 11, 2016 at 12:23 pm
  • Matthew Boehm

    Unfortunately, a bug exists ( in Galera that prevents 4K pages from working in Galera-based setups.

    August 11, 2016 at 4:45 pm
  • Twirrim

    I’ve been trying to find the internal page size of the 850 Pro, but haven’t found it yet. It looks like the 840 Pro had a 8kb page size, but it’s not clear if that continued on to the 850 Pro. If someone has an 850 Pro handy and is bored, maybe that would be worth a quick experiment as the page size?

    It certainly seems like the internal page size is something we should be aware of with storage and DB configuration, maybe pressure can be put on manufacturers to start including it in technical specs?

    August 11, 2016 at 6:44 pm
  • Peter Zaitsev


    You’re right – if you’re using Innodb Compression 4K base page is unlikely to be the good choice. Though we do not see Innodb compression (any of them) being used too frequently.

    If using compression 8K base page size with 4K compressed page size might be good idea if 2x compression is routinely reached

    August 11, 2016 at 9:57 pm
  • Peter Zaitsev


    As much as I would like to see different page size options for different tables (and perhaps even indexes) I would only like to see it if it can be done without significant code complication so we’re not getting another Innodb Compression which introduced a lot of extra complexity to the code and took years to stabilize

    August 11, 2016 at 9:59 pm
  • Peter Zaitsev


    Did you look at the database size on disk with 4K and 16K pages ? Typically you should see some increase in space usage which is what can cause additional IO.

    August 11, 2016 at 10:02 pm
    • Vadim Tkachenko


      There are size for 100 warehouses

      16K page size
      -rw-r—– 1 root root 2189426688 Aug 8 08:10 customer.ibd
      -rw-r—– 1 root root 3212836864 Aug 8 08:10 order_line.ibd
      -rw-r—– 1 root root 3753902080 Aug 8 08:10 stock.ibd

      8K page size
      -rw-r—– 1 root root 2369781760 Aug 12 01:11 customer.ibd
      -rw-r—– 1 root root 3309305856 Aug 12 01:11 order_line.ibd
      -rw-r—– 1 root root 3967811584 Aug 12 01:11 stock.ibd

      4K page size
      -rw-r—– 1 root root 2885681152 Aug 13 06:34 customer.ibd
      -rw-r—– 1 root root 3581935616 Aug 13 06:34 order_line.ibd
      -rw-r—– 1 root root 4647288832 Aug 13 06:34 stock.ibd

      August 12, 2016 at 6:45 pm
  • Peter Zaitsev

    Hi Vadim,

    So the database size on disk is 21% larger for 4K pages compared to 16K pages and 5% larger for 8K pages compared to 16K pages, which means less of it fits in memory. You also perhaps have more overhead from buffer pool when using 4K page sizes hence having less OS cache available. Both these should cause negative impact on performance.

    August 13, 2016 at 11:14 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.