Comments (12)
@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.
Related Issues (14)
- Zend OPcache HOT 3
- Disable pcre JIT compilation by default HOT 2
- PHP error on restart for EL6 HOT 4
- PHP-71u conflicts with EL7 version of OpenSSL (expects fedora OpenSSL) HOT 12
- Support for webp in php71u-gd HOT 3
- Multiple PHP-FPM instances running w/ php71u-fpm-7.1.10-1.ius.centos6.x86_64 HOT 2
- Unment dependencies when installing php71u-gd HOT 1
- any update on PHP72 package? HOT 2
- Cannot install mod_php71u + httpd24u on CentOS 6 HOT 1
- update to 7.1.23 HOT 2
- 7.1.29 HOT 3
- 7.1.30 HOT 1
- has this repo been removed? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from php71u.