网上大页的资料抄来抄去, 没一个是正确的![]() ![]() 效果对比 未配置HugePage: ![]() 配置HugePage后 (并加多客户端个数向MySQL施压): ![]() 总结: 从对比数据看出来,开启HugePage后,QPS 2~3倍,提升下, UserCPU状态只是多消耗0.2~0.5而已. Load低成3~5倍. 长短时间的运行,表情都很稳定. 大幅度减少重启后MySQL预热时间(Hit列提高几个百分点). 原理资料 大家知道,OS HugePage开启后,内存置换大幅度减少.这没什么高深的技术难度,但是很考验原理的理解和配置项的细心程度. 根据: linux kernel描述 https://www./doc/Documentation/vm/hugetlbpage.txt
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. 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-hugetlb Kernel的内存页: https://www./doc/Documentation/sysctl/kernel.txt MySQL使用HugePage: http://dev./doc/refman/5.5/en/large-page-support.html http://dev./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
我喜欢一次性把几个参数在文件中配置完. 记住用命令 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的值.
网上很多的资料说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) [OK] 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 ![]() 使用top (请忽略RES). 关注 VIRT一项. ![]() ----
-------- 最后我们可以按照MySQL defaults-file和机器的物理内存大小配置线上的HugePage参数. 我们只是配置正确,不是在"调优". <高性能MySQL>提示. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 有应聘"MySQL/MariaDB,运维/开发", 请发邮件至: linzuxiong1988@gmail.com, 并取得联系. 工程师招聘: http://job.youzan.com 请联系我: linzuxiong1988@gmail.com . |
|