让你的PHP7更快之Hugepage用法分析
本文实例讲述了让你的php7更快之hugepage用法。分享给大家供大家参考,具体如下:
php7刚刚发布了rc4, 包含一些bug修复和一个我们最新的性能提升成果(news), 那就是”hugepagefy php text segment”, 通过启用这个特性,php7会把自身的text段(执行体)”挪“到huagepage上,之前的测试,我们能稳定的在wordpress上看到2%~3%的qps提升。
关于hugepage是啥,简单的说下就是默认的内存是以4kb分页的,而虚拟地址和内存地址是需要转换的, 而这个转换是要查表的,cpu为了加速这个查表过程都会内建tlb(translation lookaside buffer), 显而易见如果虚拟页越小,表里的条目数也就越多,而tlb大小是有限的,条目数越多tlb的cache miss也就会越高, 所以如果我们能启用大内存页就能间接降低这个tlb cache miss,至于详细的介绍,google一搜一大堆我就不赘述了,这里主要说明下如何启用这个新特性, 从而带来明显的性能提升。
新的kernel启用hugepage已经变得非常容易了,以我的开发虚拟机为例(ubuntu server 14.04,kernel 3.13.0-45), 如果我们查看内存信息:
$ cat /proc/meminfo | grep huge anonhugepages: 444416 kb hugepages_total: 0 hugepages_free: 0 hugepages_rsvd: 0 hugepages_surp: 0 hugepagesize: 2048 kb
可见一个hugepage的size是2mb, 而当前并没有启用hugepages. 现在让我们先编译php rc4, 记得一定不要加: –disable-huge-code-pages (这个新特性是默认启用的, 你加了这个就关了)
然后配置opcache, 从php5.5开始opcache已经是默认启用编译的,但是是编译动态库的, 所以我们还是要在php.ini中配置加载下。
zend_extension=opcache.so
这个新特性是做在opcache里的,所以也要通过opcache启用这个特性(通过设置opcache.huge_code_pages=1), 具体的配置:
opcache.huge_code_pages=1
现在让我们配置os, 分配一些hugepages:
$ sudo sysctl vm.nr_hugepages=128 vm.nr_hugepages = 128
现在让我们再次检查内存信息:
$ cat /proc/meminfo | grep huge anonhugepages: 444416 kb hugepages_total: 128 hugepages_free: 128 hugepages_rsvd: 0 hugepages_surp: 0 hugepagesize: 2048 kb
可以看到我们分配的128个hugepages已经就绪了, 然后我们来启动php-fpm:
$ /home/huixinchen/local/php7/sbin/php-fpm [01-oct-2015 09:33:27] notice: [pool www] 'user' directive is ignored when fpm is not running as root [01-oct-2015 09:33:27] notice: [pool www] 'group' directive is ignored when fpm is not running as root
现在, 再次检查内存信息:
$ cat /proc/meminfo | grep huge anonhugepages: 411648 kb hugepages_total: 128 hugepages_free: 113 hugepages_rsvd: 27 hugepages_surp: 0 hugepagesize: 2048 kb
说到这里,如果hugepages可用, 其实opcache也会用hugepages来存储opcodes缓存, 所以为了验证opcache.huge_code_pages确实生效, 我们不妨关闭opcache.huge_code_pages, 然后再启动一次后看内存信息:
$ cat /proc/meminfo | grep huge anonhugepages: 436224 kb hugepages_total: 128 hugepages_free: 117 hugepages_rsvd: 27 hugepages_surp: 0 hugepagesize: 2048 kb
可见开启了huge_code_pages以后, fpm启动后多用了4个pages, 现在我们检查下php-fpm的text大小:
$ size /home/huixinchen/local/php7/sbin/php-fpm text data bss dec hex filename 10114565 695200 131528 10941293 a6f36d /home/huixinchen/local/php7/sbin/php-fpm
可见text段有10114565个字节大小, 总共需要占用4.8个左右的2m的pages, 考虑到对齐以后(尾部不足2m page部分不挪动), 申请4个pages, 正好和我们看到的相符。
说明配置成功! enjoy !
但是有言在先, 启用此特性以后, 会造成一个问题就是你如果尝试通过perf report/anno 去profiling的时候, 会发现符号丢失(valgrind, gdb不受影响), 这个主要原因是perf的设计采用监听了mmap,然后记录地址范围, 做ip到符号的转换, 但是目前hugetlb只支持map_anon, 所以导致perf认为这部分地址没有符号信息,希望以后版本的kernel可以修复这个限制吧..
最后: 性能对比测试的任务就留给大家来试试了, 欢迎评论你们看到的变化!
希望本文所述对大家php程序设计有所帮助。
上一篇: .NET微信公众号开发之公众号消息处理
下一篇: PHP表单数据写入MySQL数据库的代码