Opcache huge_code_pages errors on CentOS6 about php71u HOT 12 CLOSED

@BPScott, thanks for the feedback. The updated packages will get pushed to the stable repositories during tonight's automation run.

from php71u.

/cc @jayflux as the affects our testing of php71.

from php71u.

Howdy @BPScott,

Thanks for bringing this to our attention. We fork our spec files from Fedora. At the time we created php70u, the Rawhide spec file was still on 5.6 and had no mention of the opcache.huge_code_pages setting in opcache.ini. I updated our opcache.ini file based on the upstream php.ini-production example file (which had that setting commented out). As of 7.0.14 it is still commented out.

When we forked our php71u spec file, Rawhide was up to date and had that setting explicitly disabled in the ini file, but then flips the 0 to a 1 in the spec file during the build if on x86_64 hardware. That's how it is currently enabled in our EL6 (x86_64) packages. As of 7.1.0 it is still commented out in the upstream example file.

IUS stands for Inline with Upstream Stable. We consider both the upstream project and Fedora as upstream for our packages. Since upstream and Fedora are doing different things, we have to make a choice.

• disable opcache.huge_code_pages everywhere (upstream recommendation)
• enable opcache.huge_code_pages when possible (Fedora setting, would result in just enabling it on EL7 x86_64)

Which sounds better to you?

from php71u.

Thanks for the Fedora repo links @carlwgeorge, I had knew IUS tracked the Fedora specs but I wasn't confident on where Fedora kept its repo and I wasn't sure if this issue was better targeted here or to Fedora.

Both options are acceptable, I guess it comes down to who IUS considers to be the more canonical upstream.

My gut reckons tracking Fedora behaviour is preferable. If Fedora thinks the option is stable enough to use then following their lead in enabling opcache.huge_code_pages when possible sounds like a preferable option over a blanket disabling.

Should this issue also be raised to whomever maintains the Fedora repo too? I don't know is supporting RHEL6 is relevant to them.

from php71u.

Remi is the primary package maintainer of php in both Fedora and in RHEL (he is a Red Hat employee), but I can already tell you that maintaining EL6 compatibility in the Fedora spec file is not a priority. For example, they removed their sysvinit conditionals quite some time ago.

If you think that enabling it when possible is the best choice, do you think it's worth making the same change in php70u to match?

from php71u.

Keeping php70u and php71u consistent does sound useful from the principle of least surprise, assuming it's a small amount of work.

It doesn't look like the code relating to the toggle has been updated since 7.0.1 so backporting at this point does sound feasible.

Personally I have no immediate plans to upgrade away from CentOS6 so this wouldn't affect me either way.

from php71u.

So I dug into this a bit more, and I was able to reproduce that warning on a CentOS 6 cloud server.

[root@test6 ~]# service php-fpm start
Starting php-fpm: [23-Dec-2016 18:00:15] NOTICE: PHP message: PHP Warning:  Zend OPcache huge_code_pages: mmap(HUGETLB) failed: Cannot allocate memory (12) in Unknown on line 0
                                                           [  OK  ]
[root@test6 ~]# service php-fpm stop
Stopping php-fpm:                                          [  OK  ]

However, the RHEL 6 documentation indicates that EL6 does support huge pages, but the default value is 0 pages (disabled).

[root@test6 ~]# sysctl vm.nr_hugepages 
vm.nr_hugepages = 0
[root@test6 ~]# grep Huge /proc/meminfo 
AnonHugePages:      2048 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

After enabling some huge pages, php-fpm starts without issue. I can even observe that it allocated a huge page.

[root@test6 ~]# sysctl -w vm.nr_hugepages=4
vm.nr_hugepages = 4
[root@test6 ~]# grep Huge /proc/meminfo 
AnonHugePages:      2048 kB
HugePages_Total:       4
HugePages_Free:        4
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
[root@test6 ~]# service php-fpm start
Starting php-fpm:                                          [  OK  ]
[root@test6 ~]# grep Huge /proc/meminfo 
AnonHugePages:     14336 kB
HugePages_Total:       4
HugePages_Free:        3
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

It's worth emphasizing that the upstream example php.ini file states that the opcache.huge_code_pages setting "requires appropriate OS configuration". It seems like to me the best option is to build with huge page support (no --disable-huge-code-pages build flag) but leave it disabled in the configuration file for both EL6 and EL7.

P.S. Strangely enough, opcache.huge_code_pages isn't even documented in the PHP manual.

from php71u.

I've made the change, and it will be available in 7.1.0-3, which should move to the testing repositories during tonight's automation.

from php71u.

Thanks for your work on this @carlwgeorge. I see is in the 7.1.0-3 in the testing repo, I don't suppose you've got an ETA of when you're hoping to push this to stable?

from php71u.

Typically we leave our packages in the testing repositories for two weeks before promoting them to stable. That will be Saturday, but we don't push packages on the weekend, so probably Monday. However, if you have installed 7.1.0-3 from testing and can confirm the fix works as expected, I can queue it up to be promoted during tonight's automation.

from php71u.

I've installed 7.1.0-3 from testing and can confirm that it works and the warning message is gone. No need to divert from your standard release process just for me though. I'm happy to wait till Monday.

from php71u.

Going above and beyond. Thanks @b-harper <3

from php71u.