huge page 能给MySQL 带来性能提升吗？

最近一直在做性能压测相关的事情，有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page，我听说过huge page会对性能有所提升，本文就一探究竟。对过程没有兴趣的可以直接看结论。

二 Huge Page 来龙去脉

2.1 为什么需要Huge Page

在 Linux 操作系统上运行内存需求量较大的应用程序时，由于其采用的默认页面大小为 4KB，因而将会产生较多 TLB Miss 和缺页中断，从而大大影响应用程序的性能。当操作系统以 2MB 甚至更大作为分页的单位时，将会大大减少 TLB Miss 和缺页中断的数量，显著提高应用程序的性能。这也正是 Linux 内核引入大页面支持的直接原因。好处是很明显的，假设应用程序需要 2MB 的内存，如果操作系统以 4KB 作为分页的单位，则需要 512 个页面，进而在 TLB 中需要 512 个表项，同时也需要 512 个页表项，操作系统需要经历至少 512 次 TLB Miss 和 512 次缺页中断才能将 2MB 应用程序空间全部映射到物理内存；然而，当操作系统采用 2MB 作为分页的基本单位时，只需要一次 TLB Miss 和一次缺页中断，就可以为 2MB 的应用程序空间建立虚实映射，并在运行过程中无需再经历 TLB Miss 和缺页中断（假设未发生 TLB 项替换和 Swap）。

为了能以最小的代价实现大页面支持，Linux 操作系统采用了基于 hugetlbfs 特殊文件系统 2M 字节大页面支持。这种采用特殊文件系统形式支持大页面的方式，使得应用程序可以根据需要灵活地选择虚存页面大小，而不会被强制使用 2MB 大页面。via(InnoDB启用大内存页)

2.2 HugePage的优势:

1.增加TLB的命中率

2.Page是被锁定在内存中，降低内存交换；

3.锁定内存，降低内存释放与占用产生的性能降低；

4.提高内存的性能，降低CPU负载。

三 mysql 如何用huge page

不同系统的huge pages大小可能不一样，我们使用centos7 huge page 大小默认为2M 。

3.1 计算需要多少 huge pages

启用 huge page之前首先我们要计算分配多少huge page给mysql 使用。一般的建议是mysql使用的总内存大小加上10%。计算公式如下

S =  (query_cache_size + table_open_cache + innodb_buffer_pool_size + innodb_log_file_size + performance_schema.memory) + 10 %

那么 huge pages的个数大小是

vm.nr_hugepages=S/2M

3.2 设置mysql用户组使用huge pages

通过 id mysql 获取mysql所在的group id

# id mysqluid=27(mysql) gid=27(mysql) groups=27(mysql)

echo 27 > /proc/sys/vm/hugetlb_shm_group

3.3 为 mysql 用户提供memlock限制的“无限”值

编辑/etc/security/limits.conf 增加

#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - a user name
#        - @mysql 表示mysql用户组的不受限
##设置mysql 使用 HugePages
@mysql
 soft memlock unlimited
@mysql
 hard memlock unlimited

编辑 my.cnf 在[mysqld]里面增加

large_pages=1

3.4验证hugepage是否生效

# cat /proc/meminfo | grep HugeAnonHugePages:   1294336 kBHugePages_Total:    5834HugePages_Free:     1394HugePages_Rsvd:      921HugePages_Surp:        0Hugepagesize:       2048 kB

出现不为0的值,HugePagesFree小于HugePagesTotal.

3.5 启动MySQL 可能遇到的问题

在启动mysql的时候，最容易报的错误是:

[Warning] InnoDB: Failed to allocate 140509184 bytes. errno 12[Warning] InnoDB: Using conventional memory pool

出现上面的提示大概率是因为

1.nr_hugepages的值*2M小于innodb使用的内存大小，需要调整nr_hugepages 的值。

2.针对mysql用户组的 memlock 是否设置。在启动mysql时，一定要先查看用ulimit -a 来查看max locked memory 设置是否合理。

3.6 压测结果

OS centos 7.10 内核 3.10

DB 相关压测参数

两个实例一个开启和未开启大页性能无差异。和网上的资料说性能会有所提升不一致。

四总结

我根据官方文档和网上的相关资料，检查了开启内存大页的步骤没有异常，而且压测两次。如果读者朋友中有压测huge page且有性能提升的，欢迎留言相互交流学习。

参考文章

官方文档

https://dev.mysql.com/doc/refman/5.7/en/large-page-support.html

InnoDB启用大内存页

https://www.cnblogs.com/gomysql/p/3627915.html

Huge Page 是否是拯救性能的万能良药?

http://cenalulu.github.io/linux/huge-page-on-numa/