Detailed explanation of Hugepage to make PHP7 faster

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 "Move" its own TEXT segment (execution body) to Huagepage. In previous tests, we can 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 lookup, the CPU Table procedures will all have built-in TLB (Translation Lookaside Buffer). Obviously, 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 can enable large memory pages, we 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 we mainly explain how to enable this new feature, thereby bringing obvious performance promote.

It has become very easy to enable Hugepage in 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 this off)

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 built 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 us configure OS, allocate some Hugepages:

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

Now let us 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 does take effect, we might as well Close opcache.huge_code_pages, then start it again and check 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 turning on huge_code_pages, fpm uses 4 more pages after starting. 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 has a size of 10114565 bytes, which requires 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. consistent.

Indicates that the configuration is successful! Enjoy

But I have to say it first. After enabling this feature, a problem will occur. If you try to profile through Perf report/anno, you will find that symbols are lost (valgrind, gdb are not affected). The main reason is that Perf is designed to monitor mmap, then record the address range, and convert IP to symbol. However, currently HugeTLB 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...

Recommended tutorial: "PHP7"

The above is the detailed content of Detailed explanation of Hugepage to make PHP7 faster. For more information, please follow other related articles on the PHP Chinese website!