Hugepage usage analysis to make your PHP7 faster, php7hugepage_PHP tutorial

Analysis of Hugepage usage to make your PHP7 faster, php7hugepage

This article explains the Hugepage usage to make your PHP7 faster. Share it with everyone for your reference, the details are as follows:

PHP7 has just released RC4, which contains some bug fixes and one of our latest performance improvements (NEWS), which is "HugePageFy PHP TEXT segment". By enabling this feature, PHP7 will convert its own TEXT segment (execution body) "Moved" to Huagepage. In previous tests, we could steadily see a 2% to 3% QPS increase on WordPress.

Regarding what Hugepage is, to put it simply, the default memory is paged in 4KB, and the virtual address and the memory address need to be converted, and this conversion requires a table lookup. In order to speed up the table lookup process, the CPU will Built-in TLB (Translation Lookaside Buffer), it is obvious that if the virtual page is smaller, the number of entries in the table will be more, and the TLB size is limited, the more entries, the higher the Cache Miss of the TLB will be, so if we Enabling large memory pages can indirectly reduce this TLB Cache Miss. As for the detailed introduction, I will not go into details after searching a lot on Google. Here I mainly explain how to enable this new feature, which will bring significant performance improvements.

It has become very easy to enable Hugepage with the new Kernel. Taking my development virtual machine as an example (Ubuntu Server 14.04, Kernel 3.13.0-45), if we view the memory information:

$ cat /proc/meminfo | grep Huge
AnonHugePages:  444416 kB
HugePages_Total:    0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB

It can be seen that the size of a Hugepage is 2MB, and HugePages are not currently enabled. Now let us compile PHP RC4 first, remember not to add: –disable-huge-code-pages (this new feature is enabled by default, you add Turn it off after this)

Then configure opcache. Starting from PHP5.5, Opcache has been enabled for compilation by default, but it is used to compile dynamic libraries, so we still need to configure and load it in php.ini.

zend_extension=opcache.so

This new feature is implemented in Opcache, so this feature must also be enabled through Opcache (by setting opcache.huge_code_pages=1), specific configuration:

opcache.huge_code_pages=1

Now let’s configure the OS and allocate some Hugepages:

$ sudo sysctl vm.nr_hugepages=128
vm.nr_hugepages = 128

Now let’s check the memory information again:

$ cat /proc/meminfo | grep Huge
AnonHugePages:  444416 kB
HugePages_Total:   128
HugePages_Free:   128
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB

You can see that the 128 Hugepages we allocated are ready, and then we start 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

Now, check the memory information again:

$ cat /proc/meminfo | grep Huge
AnonHugePages:  411648 kB
HugePages_Total:   128
HugePages_Free:   113
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB

Speaking of which, if Hugepages is available, Opcache will actually use Hugepages to store the opcodes cache, so in order to verify that opcache.huge_code_pages is indeed effective, we might as well close opcache.huge_code_pages, and then start it again to see the memory information:

$ cat /proc/meminfo | grep Huge
AnonHugePages:  436224 kB
HugePages_Total:   128
HugePages_Free:   117
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB

It can be seen that after huge_code_pages is turned on, 4 more pages are used after fpm is started. Now let’s check the text size of php-fpm:

$ 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

It can be seen that the text segment is 10114565 bytes in size, and it needs to occupy a total of about 4.8 pages of 2M. After taking into account the alignment (the tail part less than 2M Page will not be moved), apply for 4 pages, which is exactly what we see. .

Indicates that the configuration is successful! Enjoy!

But I have to say it first, After enabling this feature, a problem will be caused. If you try to profile through Perf report/anno, you will find that symbols are missing (valgrind, gdb are not affected). The main reason for this is that Perf The design uses monitoring mmap, then records the address range, and converts IP to symbol. However, HugeTLB currently only supports MAP_ANON, so Perf thinks that this part of the address has no symbol information . I hope that future versions of Kernel can fix this limitation. ..

Finally: The performance comparison test task is left to everyone to try it. Welcome to comment on the changes you see!

I hope this article will be helpful to everyone in php programming design.

http://www.bkjia.com/PHPjc/1133041.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1133041.htmlTechArticleAnalysis of Hugepage usage to make your PHP7 faster, php7hugepage This article tells the example of Hugepage to make your PHP7 faster usage. Share it with everyone for your reference, the details are as follows: PHP7 has just been released...