Edit report at https://bugs.php.net/bug.php?id=70984&edit=1
ID: 70984
User updated by: arjen at react dot com
Reported by: arjen at react dot com
Summary: Script extreme slow compared to 5.6, MAP_HUGETLB
problem?
Status: Analyzed
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 7.0.0RC8
Block user comment: N
Private report: N
New Comment:
Optional feature?
It's optional for the opcache (see http://git.php.net/?p=php-src.git;a=commitdiff;h=669f0b39b184593e01e677360fd79b2b63058ca0
can be enabled with --enable-huge-code-pages "PHP should be configured and built with
--enable-huge-code-pages, OS should be configured to provide huge pages.")
However, the MAP_HUGETLB usage in https://github.com/php/php-src/commit/6848cb3f6301db11e1925f4457c0b58c2d169ccf#diff-a87834df314cdb8a36e48f69764933b0L462
cannot be disabled. And if the OS isn't configured to provide huge pages (but MAP_HUGETBL is
stil defined), every mmap call with MAP_HUGETBL apparantly fails.
Previous Comments:
------------------------------------------------------------------------
[2015-12-08 14:49:06] rasmus@php.net
But why compile in this optional feature if you are not going to use it?
I would assume that general-purpose distro builds are not going to compile in this option.
------------------------------------------------------------------------
[2015-12-08 09:40:43] sjon at hortensius dot net
Yes, this is all obvious. This behavior is caused by https://github.com/php/php-src/commit/6848cb3f6301db11e1925f4457c0b58c2d169ccf
which I think might be a good change as hugepages CAN result in a performance increase; however it
seems to cause more issues that it's worth currently (as misses are too costly).
Documenting nr_hugepages isn't going to fix the significant slowdowns that this feature
currently causes
------------------------------------------------------------------------
[2015-12-08 09:39:49] yohgaki@php.net
@sjon
Your guess seems right. I rebooted my system with 1 huge page and I only get slower PHP 7.0
execution only at the first time.
I should have gotten strace output when my system was performing poorly.
Anyway, PHP may handle mmap error more gracefully.
------------------------------------------------------------------------
[2015-12-08 09:28:24] yohgaki@php.net
Huge page setting affects more for 7.0.
I observed extremely slow execution (60 secs or more) on occasion when HugePages_Total is 1. The
reporter's system uses no huge page and experiences slow execution. My Fedora 22 seems
performing better without huge page.
It seems we are better to document huge page setting some where in the manual.
------------------------------------------------------------------------
[2015-12-08 09:20:44] sjon at hortensius dot net
Adding vm.nr_hugepages will claim a few pages as huge; making the allocation work. @yohgaki: it will
probably be the reboot that 'fixes' this for you, like I already posted.
However, PHP should fail better when no hugepages can be allocated. Imo the allocator should store a
HUGETLB failure for x number of runs / time instead of keep trying (which seems to have a
significant impact on performance).
Increasing nr_hugepages is a workaround; and potentially claims memory that can not be used by
applications not using HUGETLB allocations.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=70984
--
Edit this bug report at https://bugs.php.net/bug.php?id=70984&edit=1