php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #77862 opcache.huge_code_pages can not be disabled
Submitted: 2019-04-07 01:21 UTC Modified: 2019-04-08 08:43 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: hawu at fast-mail dot one Assigned:
Status: Open Package: opcache
PHP Version: 7.3Git-2019-04-07 (snap) OS: Debian 9
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hawu at fast-mail dot one
New email:
PHP Version: OS:

 

 [2019-04-07 01:21 UTC] hawu at fast-mail dot one 
Description:
------------
php --version
PHP 7.3.3-1+0~20190307202245.32+stretch~1.gbp32ebb2 (cli) (built: Mar  7 2019 20:22:46) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.3-1+0~20190307202245.32+stretch~1.gbp32ebb2, Copyright (c) 1999-2018, by Zend Technologies


Using Debian 9 with 1GB hugepages configured as such: "transparent_hugepage=never default_hugepagesz=1GB hugepagesz=1GB hugepages=4"

Setting opcache.huge_code_pages=0 will NOT disable usage of huge pages.


# cat /etc/php/7.3/fpm/php.ini | grep  opcache.
[opcache]
opcache.enable=1
;opcache.enable_cli=0
opcache.memory_consumption=256
;opcache.interned_strings_buffer=8
;opcache.max_accelerated_files=10000
;opcache.max_wasted_percentage=5
;opcache.use_cwd=1
;opcache.validate_timestamps=1
;opcache.revalidate_freq=2
;opcache.revalidate_path=0
;opcache.save_comments=1
;opcache.enable_file_override=0
;opcache.optimization_level=0x7FFFBFFF
;opcache.dups_fix=0
;opcache.blacklist_filename=
;opcache.max_file_size=0
;opcache.consistency_checks=0
;opcache.force_restart_timeout=180
;opcache.error_log=
;opcache.log_verbosity_level=1
;opcache.preferred_memory_model=
;opcache.protect_memory=0
;opcache.restrict_api=
;opcache.mmap_base=
;opcache.file_cache=
;opcache.file_cache_only=0
;opcache.file_cache_consistency_checks=1
;opcache.file_cache_fallback=1
opcache.huge_code_pages=0
;opcache.validate_permission=0
;opcache.validate_root=0
;opcache.opt_debug_level=0
# cat /proc/meminfo | grep HugePages_
HugePages_Total:       4
HugePages_Free:        3
HugePages_Rsvd:        0
HugePages_Surp:        0
# service php7.3-fpm stop
# cat /proc/meminfo | grep HugePages_
HugePages_Total:       4
HugePages_Free:        4
HugePages_Rsvd:        0
HugePages_Surp:        0


However setting opcache.enabled=0 (or stopping php7.3-fpm) will result in huge pages not being used. 


Changing opcache.memory_consumption DOES have an effect of huge pages (setting it to 1500 will reserve an additional 1 GB huge page)

cat /proc/meminfo | grep HugePages_
HugePages_Total:       4
HugePages_Free:        3
HugePages_Rsvd:        1
HugePages_Surp:        0


There does not seem to be a way to use opcache without using huge pages. The only way to not use huge pages is to disable cache completely via opcache.enabled=0.

Also, looking at the output of "print_r(opcache_get_configuration())" does not mention opcache.huge_code_pages regardless of how it is configured (it does show status of opcache.enabled, opcache.memory_consumption and others).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-04-07 01:31 UTC] hawu at fast-mail dot one
-Package: PHP options/info functions +Package: opcache
 [2019-04-07 01:31 UTC] hawu at fast-mail dot one 
.
 [2019-04-08 08:43 UTC] nikic@php.net 
The opcache.huge_code_pages controls the use of huge pages for the PHP binary itself, not for shared memory. Shared memory will use huge pages unconditionally if available.

What is the motivation for disabling use of huge pages here? We've disabled the use of huge pages by default in the primary allocator (recently also the use of transparent huge pages) due to performance issues in constrained systems. Are you seeing similar issues with the use of huge pages for opcache SHM? This seems like a pretty ideal use-case for them, because this is a large and static allocation.
 [2019-04-16 10:59 UTC] hawu at fast-mail dot one 
Thanks for clearing that up. I didn't find any info on that online when I searched for it. In regards to performance, I have not tested. The 'issue' is the provisioning of the huge pages. In this case, 1 gb extra needs to be allocated.
 [2020-12-11 18:57 UTC] nnewton at tag1consulting dot com 
We recently hit this while creating a php deployment on a fairly restrictive Kubernetes platform. Kubernetes allows you to schedule hugepages as an allocatable resource and I think the documentation here doesn't make it clear what will happen if hugepages appear available, but aren't actually allocatable. By that I mean we were chasing this error:

[root@huge-pages-test /]# php -v
Bus error (core dumped)

What is happening here is the php is detecting hugepages and trying to allocate, but is not being allowed via cgroups because the Kubernetes manifest for this php deployment doesn't include a hugepages request. There doesn't seem to be any way to realistically turn this attempted allocation off, so PHP just requires hugepages on Kubernetes platforms that have huge pages available as it stands right now. That maybe intended, but the documentation doesn't make that clear in my view.

I am not sure if this is the correct bug report to add this to, but I think the documentation here needs to be a bit clearer.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 18:01:29 2024 UTC