Bug #70984 [Ana]: Script extreme slow compared to 5.6, MAP_HUGETLB problem?

Edit report at https://bugs.php.net/bug.php?id=70984&edit=1 ID: 70984 Updated by: rasmus@php.net 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: 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 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. ------------------------------------------------------------------------ [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 -- Edit this bug report at https://bugs.php.net/bug.php?id=70984&edit=1