To use an alternate page size, edit innobase/include/univ.i to change these:
/* The universal page size of the database */Does InnoDB support 4kb pages? Maybe. If you edit the fields listed above for a 4kb page size and run MySQL, you will quickly get a core dump. The problem is that there are other per-page objects that are too big for a 4kb page. The first problem I encountered is fixed by editing innobase/include/trx0rseg.h to reduce the number of rollback segment slots per page. The default value is:
#define UNIV_PAGE_SIZE (2 * 8192)
/* The 2-logarithm of UNIV_PAGE_SIZE: */
#define UNIV_PAGE_SIZE_SHIFT 14
#define TRX_RSEG_N_SLOTS 1024To be really safe, I set it to 256 and the segfault was fixed. I haven't done testing beyond this so your mileage may vary.
InnoDB had a 900 byte per-page overhead when I last measured this. 900 bytes per 4kb page is much worse than per 16kb page. I am not sure when this will get fixed.


Do you actually want smaller/other page sizes, or just curious?
ReplyDeleteIIRC peterz tried 64k pages and decided it wasn't worth it, performance wise.
I want smaller pages for disk-bound OLTP workloads. This should provide a moderate benefit with SATA and a larger benefit with Intel SSD. To confirm I will test on SATA soon. Alas, I don't have an Intel SSD yet.
ReplyDeleteSmall pages will decrease the performance of index scans (but not lookups), but should increase efficiency of the buffer cache. It can also decrease page/block contention but I don't know if it is an issue with InnoDB.
ReplyDeleteThe workload for which I want to try this is extremely IO bound with mostly index lookups and few scans.
ReplyDeleteMark, we need to get you an intel SSD ... :)
ReplyDeleteI too compiled with 4k pages to test... With SSD there might be a performance boost here.
Though 900 byte overhead could be improved.
Also, making this a configurable might help find bugs sooner...