mysql hugepage_Linux HugePage for MySQL Server(MySQL中大页的使用)

最新推荐文章于 2021-09-06 07:27:05 发布

樊反

最新推荐文章于 2021-09-06 07:27:05 发布

阅读量173

点赞数

文章标签： mysql hugepage

本文链接：https://blog.csdn.net/weixin_28953877/article/details/113907678

版权

本文总结了在Linux环境下为MySQL配置HugePage的实践经验，通过对比未配置前后的效果，展示了启用HugePage能显著提升QPS，并降低UserCPU和Load。介绍了相关原理和配置步骤，包括调整Linux内核参数、设置MySQL配置等。

摘要由CSDN通过智能技术生成

Linux HugePage for MySQL Server(MySQL中大页的使用) 网上大页的资料抄来抄去, 没一个是正确的 :shock: . 本人经过查Linux说明和实践, 现将线上的配置总结一下. :lol: 效果对比未配置HugePage: 配置HugePage后 (并加多客户端个数向MySQL施压): 总结: 从对

Linux HugePage for MySQL Server(MySQL中大页的使用)

网上大页的资料抄来抄去, 没一个是正确的 :shock: . 本人经过查Linux说明和实践, 现将线上的配置总结一下. :lol:

效果对比

未配置HugePage:

配置HugePage后 (并加多客户端个数向MySQL施压):

总结: 从对比数据看出来,开启HugePage后,QPS 2~3倍,提升下, UserCPU状态只是多消耗0.2~0.5而已.? Load低成3~5倍. 长短时间的运行,表情都很稳定. 大幅度减少重启后MySQL预热时间(Hit列提高几个百分点).

原理资料

大家知道,OS HugePage开启后,内存置换大幅度减少.这没什么高深的技术难度,但是很考验原理的理解和配置项的细心程度.

linux kernel描述

https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

*HugePages_Total is the size of the pool of huge pages.

*HugePages_Free is the number of huge pages in the pool that are not yet

allocated.

*HugePages_Rsvd is short for "reserved," and is the number of huge pages for

which a commitment to allocate from the pool has been made,

but no allocation has yet been made. Reserved huge pages

guarantee that an application will be able to allocate a

huge page from the pool of huge pages at fault time.

*HugePages_Surp is short for "surplus," and is the number of huge pages in

the pool above the value in /proc/sys/vm/nr_hugepages. The

maximum number of surplus huge pages is controlled by

/proc/sys/vm/nr_overcommit_hugepages.

HugePages_Total , HugePages_Free , HugePages_Rsvd , HugePages_Surp 都是页的个数. 其中每页的大小和Linux Kernel密切相关. 例如: centos 6 x64上是2MB 一个HugePage.

HugePages_Rsvd 上面说明是保留的页数.

内存页置换原理:

http://www.ibm.com/developerworks/cn/linux/l-cn-hugetl

Kernel的内存页:

https://www.kernel.org/doc/Documentation/sysctl/kernel.txt

MySQL使用HugePage

http://dev.mysql.com/doc/refman/5.5/en/large-page-support.html

http://dev.mysql.com/doc/refman/5.6/en/large-page-support.html

我们在Linux上,使用命令查看相关的Huge Page在OS上的参数.

$ cat /proc/meminfo | fgrep -i Huge

AnonHugePages: 5775360 kB

HugePages_Total: 47872

HugePages_Free: 4304

HugePages_Rsvd: 361

HugePages_Surp: 0

Hugepagesize: 2048 kB

环境

前面属述的效果图相关环境如下:

CentOS release 6.5 (Final)

Linux 2.6 x86_64

MySQL 5.5 (5.6也有一样有2~3倍提升)

配置

*Linux OS*

* vm.nr_hugepages = 47872 #开启47872个大页. 相当于

* vm.hugetlb_shm_group = 499 #可以使用的HugePage,Linux进程相关的用户组ID

* kernel.shmmax = 94489280512 # Controls the maximum shared segment size, in bytes #单个进程下最大能使用的HugePage个数

* kernel.shmall = 230686720 # Controls the maximum number of shared memory segments, in pages. default page size : 4KB #Linux System整个所能使用的个数

我喜欢一次性把几个参数在文件中配置完. 记住用命令 sysctl -p生效之.

MySQL --defaults-file 中开启

[mysqld]

large-pages

参数大小计算说明和示例

numastat 可以看到当前系统下numa状态.

注意MySQL manual提示 : For MySQL usage, you normally want the value of shmmax to be close to the value of shmall. 我们尽量的把shmmax -> 接近 shmall的值.

_steps:

1. 确定机器的CPU processors ( 指我们在Linux命令看到的个数. cat /proc/cpuinfo | fgrep -i 'processor' | wc -l )

2. 确定MySQL每个connection所消耗的内存, 我们可以使用mysqltuner.pl 查看到 [url]http://mysqltuner.com/[/url]

**网上很多的资料说BufferPool 配置到80%的物理内存, 是有道理的, 同时这是有前提的max_connections是很少的.

总的使用内存不能超过物理内存的90%. (这个原理需要单独写篇BLOG) **

我的配置示例是

CPU 32 processors .

#选择 mysql my.cnf

max_connections = 3000 # 约47GB

innodb_buffer_pool_size = 84480M

innodb_buffer_pool_instances = 30 #每个instance是2.75GB. 因为每个在2.5GB~3GB是很高效的, 体现在MySQL RT上. 而30(CPU 32)这个数量容易计算.留一两个processors给系统. ##而每个实例会多占用近100MB的HugePage

-------------------------------------------------------------------------

###加上其他的conns消耗:

# Total buffers: 83.0G global + 16.2M per thread (3000 max threads)

# Maximum possible memory usage: 130.7G (82% of installed RAM))

这样用 30+4 (留足一定的Huge Pages给MySQL和系统其他用).

vm.nr_hugepages = 47872 ( HugePages_Total : 47872 34*2.75GB / 2MB ) <<< 物理内存的80%.*

kernel.shmmax = 94489280512 ( 32*2.75GB = 94489280512 bytes )

kernel.shmall = 230686720 ( 32*2.75 GB / 4KB = 230686720 ) (其中: 4KB 是LinuxKernelPage基本大小.)

注意

如果不留足vm.nr_hugepages , MySQL启动会报错误,启动不了!

看看MySQL 占用效果:

ipcs | fgrep mysql