FAQ
Edit report at https://bugs.php.net/bug.php?id=70984&edit=1

  ID: 70984
  Updated by: rasmus@php.net
  Reported by: arjen@react.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:

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.


Previous Comments:
------------------------------------------------------------------------
[2015-12-08 09:40:43] sjon@hortensius.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@hortensius.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.

------------------------------------------------------------------------
[2015-12-08 09:15:26] yohgaki@php.net

It appears vm.nr_hugepages=0 helped also.

PHP 7.0 debug build
[yohgaki@dev PHP-7.0]$ time ./php-bin t.php

real 0m0.839s
user 0m0.812s
sys 0m0.026s
[yohgaki@dev PHP-7.0]$ time ./php-bin t.php

real 0m0.847s
user 0m0.819s
sys 0m0.027s


PHP 5.6 Fedora 22 rpm package
[yohgaki@dev PHP-7.0]$ time php t.php

real 0m1.166s
user 0m0.805s
sys 0m0.195s
[yohgaki@dev PHP-7.0]$ time php t.php

real 0m1.012s
user 0m0.816s
sys 0m0.205s

------------------------------------------------------------------------


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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 14 | next ›
Discussion Overview
groupphp-bugs @
categoriesphp
postedNov 27, '15 at 12:54p
activeApr 3, '16 at 4:22a
posts14
users4
websitephp.net

People

Translate

site design / logo © 2017 Grokbase