讓你的PHP7更快之Hugepage用法分析
本文實例講述了讓你的PHP7更快之Hugepage用法。分享給大家供大家參考,具體如下:
PHP7剛剛發(fā)布了RC4, 包含一些bug修復(fù)和一個我們最新的性能提升成果(NEWS), 那就是”HugePageFy PHP TEXT segment”, 通過啟用這個特性,PHP7會把自身的TEXT段(執(zhí)行體)”挪“到Huagepage上,之前的測試,我們能穩(wěn)定的在Wordpress上看到2%~3%的QPS提升。
關(guān)于Hugepage是啥,簡單的說下就是默認的內(nèi)存是以4KB分頁的,而虛擬地址和內(nèi)存地址是需要轉(zhuǎn)換的, 而這個轉(zhuǎn)換是要查表的,CPU為了加速這個查表過程都會內(nèi)建TLB(Translation Lookaside Buffer), 顯而易見如果虛擬頁越小,表里的條目數(shù)也就越多,而TLB大小是有限的,條目數(shù)越多TLB的Cache Miss也就會越高, 所以如果我們能啟用大內(nèi)存頁就能間接降低這個TLB Cache Miss,至于詳細的介紹,Google一搜一大堆我就不贅述了,這里主要說明下如何啟用這個新特性, 從而帶來明顯的性能提升。
新的Kernel啟用Hugepage已經(jīng)變得非常容易了,以我的開發(fā)虛擬機為例(Ubuntu Server 14.04,Kernel 3.13.0-45), 如果我們查看內(nèi)存信息:
$ 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. 現(xiàn)在讓我們先編譯PHP RC4, 記得一定不要加: –disable-huge-code-pages (這個新特性是默認啟用的, 你加了這個就關(guān)了)
然后配置opcache, 從PHP5.5開始Opcache已經(jīng)是默認啟用編譯的,但是是編譯動態(tài)庫的, 所以我們還是要在php.ini中配置加載下。
zend_extension=opcache.so
這個新特性是做在Opcache里的,所以也要通過Opcache啟用這個特性(通過設(shè)置opcache.huge_code_pages=1), 具體的配置:
opcache.huge_code_pages=1
現(xiàn)在讓我們配置OS, 分配一些Hugepages:
$ sudo sysctl vm.nr_hugepages=128 vm.nr_hugepages = 128
現(xiàn)在讓我們再次檢查內(nèi)存信息:
$ 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已經(jīng)就緒了, 然后我們來啟動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
現(xiàn)在, 再次檢查內(nèi)存信息:
$ 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確實生效, 我們不妨關(guān)閉opcache.huge_code_pages, 然后再啟動一次后看內(nèi)存信息:
$ 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, 現(xiàn)在我們檢查下php-fpm的text大?。?/p>
$ 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個字節(jié)大小, 總共需要占用4.8個左右的2M的pages, 考慮到對齊以后(尾部不足2M Page部分不挪動), 申請4個pages, 正好和我們看到的相符。
說明配置成功! Enjoy !
但是有言在先, 啟用此特性以后, 會造成一個問題就是你如果嘗試通過Perf report/anno 去profiling的時候, 會發(fā)現(xiàn)符號丟失(valgrind, gdb不受影響), 這個主要原因是Perf的設(shè)計采用監(jiān)聽了mmap,然后記錄地址范圍, 做IP到符號的轉(zhuǎn)換, 但是目前HugeTLB只支持MAP_ANON, 所以導致Perf認為這部分地址沒有符號信息,希望以后版本的Kernel可以修復(fù)這個限制吧..
最后: 性能對比測試的任務(wù)就留給大家來試試了, 歡迎評論你們看到的變化!
希望本文所述對大家php程序設(shè)計有所幫助。
相關(guān)文章
PHP中include與require使用方法區(qū)別詳解
這篇文章詳細介紹了PHP中include與require使用方法的區(qū)別,有需要的朋友可以參考一下2013-10-10
Zend Framework上傳文件重命名的實現(xiàn)方法
這篇文章主要介紹了Zend Framework上傳文件重命名的實現(xiàn)方法,結(jié)合實例形式分析了Zend Framework上傳文件重命名的具體操作步驟與配置、檢測、重命名操作的相關(guān)實現(xiàn)技巧,需要的朋友可以參考下2016-11-11
PHP spl_autoload_register實現(xiàn)自動加載研究
spl_autoload_register()函數(shù)應(yīng)該是主流框架使用最多的也是非常核心的函數(shù)之一,可實現(xiàn)自動注冊函數(shù)和類,實現(xiàn)類似__autoload() 函數(shù)功能,簡化了類的調(diào)用與加載,提高了工作的效率2011-12-12
php控制反轉(zhuǎn)與依賴注入的實現(xiàn)介紹
IOC-Inversion of Control,即控制反轉(zhuǎn)。它不是什么技術(shù),而是一種設(shè)計思想。這篇文章主要介紹了php控制反轉(zhuǎn)與依賴注入的實現(xiàn),具有一定的參考價值,感興趣的小伙伴們可以參考一下2022-09-09
mysql 中InnoDB和MyISAM的區(qū)別分析小結(jié)
InnoDB和MyISAM是在使用MySQL最常用的兩個表類型,各有優(yōu)缺點,視具體應(yīng)用而定。基本的差別為:MyISAM類型不支持事務(wù)處理等高級處理,而InnoDB類型支持。MyISAM類型的表強調(diào)的是性能,其執(zhí)行數(shù)度比InnoDB類型更快,但是不提供事務(wù)支持,而InnoDB提供事務(wù)支持已經(jīng)外部鍵等高級數(shù)據(jù)庫功能。2008-04-04

