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:
Added ability to disable huge pages in Zend Memeory Manager through tâ¦
â¦he environment variable USE_ZEND_ALLOC_HUGE_PAGES=0.
https://github.com/php/php-src/commit/945a661912612cdecd221cd126feda7d4335c33c
So like I said, it's not optional. At least it can be disabled now. But only on trunk, not 7.0?
Previous Comments:
------------------------------------------------------------------------
[2015-12-08 15:29:10] arjen at react dot com
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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