Make your PHP7 faster hugepage usage Analysis _php techniques

The examples in this article tell you how to make your PHP7 faster hugepage usage. Share to everyone for your reference, specific as follows:

PHP7 just released RC4, including bug fixes and one of our latest performance gains (news), which is "hugepagefy PHP text segment", by enabling this feature, PHP7 will "move" its own text segment (actuator) To Huagepage, before the test, we can stable in WordPress see 2%~3% QPS Ascension.

About Hugepage is what, simple to say is the default memory is 4KB paging, and the virtual address and memory address need to convert, and this conversion is to check the table, the CPU in order to speed up this look-up table process will build TLB (translation lookaside Buffer) , obviously if the smaller the virtual page, the number of entries in the table more, and the TLB size is limited, the more entries the TLB cache Miss will be higher, so if we can enable large memory page can indirectly reduce the TLB cache Miss, as detailed introduction, Google to search a lot of I will not repeat, here is the main description of how to enable this new feature, resulting in a significant performance improvement.

The new Kernel enabled Hugepage has become very easy, taking my virtual machine for example (Ubuntu Server 14.04,kernel 3.13.0-45) If we look at 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 is visible that the size of a hugepage is 2MB, and Hugepages is not currently enabled. Now let's compile the PHP RC4, remember to not add: –disable-huge-code-pages (this new feature is enabled by default, you add this is off)

Then configure Opcache, starting from PHP5.5 Opcache is already enabled by default, but it is compiling the dynamic library, so we still have to configure the load in php.ini.

Zend_extension=opcache.so

This new feature is done in Opcache, so you also have to enable this feature via Opcache (by setting Opcache.huge_code_pages=1), specific configuration:

Opcache.huge_code_pages=1

Now let's configure the OS and assign 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

We can see that the 128 hugepages we've allocated are ready, and then we'll 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 are not running as root
[01-oct-2015 09:33:27] NOTICE: [Pool www] ' group ' directive be ignored when FPM are 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:
hugepages_surp:    0
hugepagesize:    2048 KB

Speaking of this, if Hugepages is available, in fact Opcache will also use Hugepages to store opcodes cache, so in order to verify that opcache.huge_code_pages does come into effect, we might as well close Opcache.huge_code _pages, then start again and look at the memory information:

$ cat/proc/meminfo | grep Huge
anonhugepages:  436224 kB
hugepages_total: 128 hugepages_free
:   117
HUGEPAGES_RSVD:
hugepages_surp:    0
hugepagesize:    2048 KB

Visible after the opening of the Huge_code_pages, FPM started after the use of more than 4 pages, now we check the php-fpm text size:

$ 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

Visible text segment has 10,114,565 byte size, the total need to occupy 4.8 or so 2M of pages, taking into account after the alignment (the tail is not moving the 2M page part), apply 4 pages, just as we see fit.

Description Configuration Success! Enjoy!

But pre-announced, when you enable this feature, the problem is that if you try to profiling through perf Report/anno, you will find that the symbol is missing (Valgrind, GDB is not affected), The main reason is that Perf's design used to listen to the mmap, and then record the address range, do IP to symbolic conversion, but the current hugetlb only support Map_anon, so that perf think this part of the address has no symbolic information , Hopefully later versions of kernel can fix this limit.

Finally: The performance of the test task is left to try, and welcome to comment on the changes you have seen!

I hope this article will help you with the PHP program design.