I started to use huge pages for the benchmarks I do with Postgres and MySQL/InnoDB. It helps performance but requires a few more steps to get working and this will be another source of failures for production deployments. See here for an example of the perf improvements.
Disclaimer - I am new to this and far from an expert.
Postgres
As always, the Postgres docs are useful:
- Figure out how many huge pages will be needed, call this X
- Edit /etc/sysctl.conf with vm.nr_huge_pages=$X
- sudo sysctl -p
- Compact the Linux VM (optional, not in the PG docs)
- Add huge_pages=try or huge_pages=on to the Postgres configuration
- Start Postgres
$ grep Huge /proc/meminfoAnonHugePages: 0 kBShmemHugePages: 0 kBFileHugePages: 0 kBHugePages_Total: 0HugePages_Free: 0HugePages_Rsvd: 0HugePages_Surp: 0Hugepagesize: 2048 kBHugetlb: 0 kB
sync; sync; sync
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/vm/compact_memory
MySQL/InnoDB
The docs are here for InnoDB with huge pages although I think they need to be updated. AFAIK InnoDB always uses mmap now, while it used to use shm (shmget, shmat) prior to modern 8.0. When shm is used you need to worry about /proc/sys/vm/hugetlb_shm_group, /proc/sys/kernel/shmmax and /proc/sys/kernel/shmmall as mentioned in the InnoDB docs. I don't think those need to be updated now that InnoDB appears to always use mmap. For the 5.7 code that uses shm see here and for modern 8.0 that uses mmap see here.
To use huge pages with InnoDB:
- Figure out how many huge pages will be needed, call this X. See the Postgres section above.
- Edit /etc/sysctl.conf with vm.nr_huge_pages=$X
- sudo sysctl -p
- Compact the Linux VM (optional, not in the InnoDB docs). See the Postgres section above.
- Confirm that innodb_buffer_pool_chunk_size is larger than the huge page size. The default is 128M which is great when the huge page size is 2M.
- Add large_pages=ON to my.cnf
- Start mysqld
No comments:
Post a Comment