Make PHP7 faster and analyze Hugepage usage, php7hugepage

Make PHP7 faster and analyze Hugepage usage, php7hugepage

This example describes how to use Hugepage to make PHP 7 faster. We will share this with you for your reference. The details are as follows:

PHP7 has just released RC4, which includes some bug fixes and our latest performance improvement (NEWS), which is "HugePageFy php text segment". By enabling this feature, PHP7 moves its TEXT segment (execution body) to the Huagepage. In the previous test, we can see 2% ~ 3% QPS increase.

What is Hugepage, simply put, the default memory is 4 kb paging, and the virtual address and memory address need to be converted, and the conversion is to look up the table, the CPU has built-in TLB (Translation Lookaside Buffer) to accelerate this lookup process. Obviously, the smaller the virtual page, the more entries in the table, and the smaller the TLB, the higher the number of entries, the higher the TLB Cache Miss. Therefore, if we can enable a large memory page, we can indirectly reduce the TLB Cache Miss. For details, I will not go into details when Google searches a lot. Here I will mainly explain how to enable this new feature to bring about significant performance improvements.

The new Kernel has become very easy to enable Hugepage. Take my Development Virtual Machine as an example (Ubuntu Server 14.04, Kernel 3.20.- 45). If we view the memory information:

$ cat /proc/meminfo | grep HugeAnonHugePages:  444416 kBHugePages_Total:    0HugePages_Free:    0HugePages_Rsvd:    0HugePages_Surp:    0Hugepagesize:    2048 kB

The size of a Hugepage is 2 MB, but HugePages is not enabled currently. now let's compile PHP RC4 first. Remember not to add:-disable-huge-code-pages. (This new feature is enabled by default. If you add this feature, it will be disabled)

Then configure opcache. Opcache has enabled compilation by default since PHP5.5, but it is used to compile the dynamic library. Therefore, we need to configure and load it in php. ini.

zend_extension=opcache.so

This new feature is implemented in Opcache, so you must also enable this feature through Opcache (by setting opcache. huge_code_pages = 1). The specific configuration is as follows:

opcache.huge_code_pages=1

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

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

Now let's check the memory information again:

$ cat /proc/meminfo | grep HugeAnonHugePages:  444416 kBHugePages_Total:   128HugePages_Free:   128HugePages_Rsvd:    0HugePages_Surp:    0Hugepagesize:    2048 kB

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

$ cat /proc/meminfo | grep HugeAnonHugePages:  411648 kBHugePages_Total:   128HugePages_Free:   113HugePages_Rsvd:    27HugePages_Surp:    0Hugepagesize:    2048 kB

If Hugepages is available, Opcache uses Hugepages to store the opcodes cache. huge_code_pages does take effect. We may close opcache. huge_code_pages:

$ cat /proc/meminfo | grep HugeAnonHugePages:  436224 kBHugePages_Total:   128HugePages_Free:   117HugePages_Rsvd:    27HugePages_Surp:    0Hugepagesize:    2048 kB

It can be seen that after huge_code_pages is enabled, four 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   filename10114565   695200   131528   10941293   a6f36d   /home/huixinchen/local/php7/sbin/php-fpm

It can be seen that the text segment has a size of 10114565 bytes, which requires a total of about 4.8 pages of 2 MB. Considering the alignment (the part with less than 2 MB pages at the end does not move), apply for 4 pages, exactly match what we see.

The configuration is successful! Enjoy!

However, if you try to use Perf report/anno to profiling, you will find that the symbols are lost (valgrind, gdb is not affected ), this is mainly because Perf is designed to listen to mmap, record the address range, and convert the IP address to the symbol. However, HugeTLB currently only supports MAP_ANON, therefore, Perf considers that this part of the address has no symbolic information. We hope that later versions of Kernel can fix this restriction ..

Finally, the task of performance comparison testing will be left for you to try. Welcome to comment on the changes you have seen!

I hope this article will help you with php programming.