php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77862 opcache.huge_code_pages can not be disabled
Submitted: 2019-04-07 01:21 UTC Modified: 2019-04-08 08:43 UTC
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
Have you experienced this issue?
Rate the importance of this bug to you:

 [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

Add a Patch

Pull Requests

Add a Pull Request

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.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 17:01:26 2019 UTC