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), 如果我们查看内存信息:
1 2 3 4 5 6 7 | $ 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中配置加载下。
1 | zend_extension = opcache . so |
这个新特性是做在Opcache里的,所以也要通过Opcache启用这个特性(通过设置opcache.huge_code_pages=1), 具体的配置:
1 | opcache . huge_code_pages = 1 |
现在让我们配置OS, 分配一些Hugepages:
1 2 | $ sudo sysctl vm . nr_hugepages = 128 vm . nr_hugepages = 128 |
现在让我们再次检查内存信息:
1 2 3 4 5 6 7 | $ 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:
1 2 3 | $ / 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 |
现在, 再次检查内存信息:
1 2 3 4 5 6 7 | $ 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, 然后再启动一次后看内存信息:
1 2 3 4 5 6 7 | $ 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大小:
1 2 3 | $ 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可以修复这个限制吧..
文章转载来自:trustauth.cn