Repository navigation
Addition of a max memory limit ini setting #17951
Description
Description
I'd like a max_memory_limit (naming?) ini setting to ensure that PHP never raises the memory_limit ini setting higher than a certain point. This setting should not be editable using ini_set. I'd be open to placing the max_memory_limit setting somewhere else.
Example scenario:
Running a PHP application in Kubernetes you'd have set some resource constraints. Let's say you've allocated 256 MB to a pod running the application and set memory_limit to 128 MB in php.ini.
This setup means we'll have 128 MB available in PHP and a buffer of 128 MB for the rest of the pod. (Assuming only one PHP script will be executed simultaneously, since memory_limit is per script)
Now to the issue. PHP has support for changing the memory_limit setting using the ini_set function during runtime.
If the memory_limit is set to a value higher than the total allocated memory in the pod (256 MB in this scenario), then when the pod's memory of 256 MB has been exhausted by PHP, it will be the kernel OOM killer that handles the exhaustion instead of PHP. The OOM killer then sends PHP a SIGKILL signal which causes a non-graceful exit. (Meaning that potential shutdown handler(s) registered using register_shutdown_function() won't get to run)
Suggested behaviour
php.ini:
memory_limit = "128M"
max_memory_limit = "256M"PHP code:
<?php
echo ini_get('memory_limit'); // Output: 128M
ini_set('memory_limit', '256M');
echo ini_get('memory_limit'); // Output: 256M
ini_set('memory_limit', '512M'); // Maybe this should cause a PHP notice?
echo ini_get('memory_limit'); // Output: 256M
// Attempt at working around by setting max_memory_limit
ini_set('max_memory_limit', '512M'); // Should have no effect. Maybe this should cause a PHP notice/warning/fatal?
ini_set('memory_limit', '512M'); // Maybe this should cause a PHP notice?
echo ini_get('memory_limit'); // Output: 256M
Activity
NattyNarwhal commentedon Feb 28, 2025
The alternative might be making
memory_limitno longerPHP_INI_ALLto prevent it from being set at runtime.frederikmillingpytlick commentedon Mar 1, 2025
@NattyNarwhal that would be a great alternative and probably a lot easier to implement.
The whole idea of changing the
memory_limitduring runtime is absurd from a DevOps perspective.NattyNarwhal commentedon Mar 1, 2025
It's unusual to me as well; I suspect it might have been locked down with safe mode in the before times, but that's since been long gone.
Making it per-dir/system is trivial, but it might be a breaking change and/or justify an RFC. I'll let others chime in on that (and the history too).
kocoten1992 commentedon Mar 1, 2025
Changing config at runtime is useful, I tend to keep all config at default and modify it at runtime as I see fit, it save me the trouble of changing config per script..
frederikmillingpytlick commentedon Mar 2, 2025
@kocoten1992
I see your point—being able to tweak config at runtime is definitely a time-saver for PHP developers. I often appreciate that flexibility myself. That said, I’m generally wary of runtime config changes as a whole and would prefer a world where they’re more locked down. Still, I’m fine with leaving that debate aside for now.
My concern specifically with
memory_limitis that its runtime mutability makes it tough to ensure PHP application stability. Without a ceiling, it’s hard to predict or control resource usage reliably. That’s why I’m suggesting amax_memory_limitsetting to cap any runtime changes tomemory_limit, giving us a safety net. Alternatively, lockingmemory_limitto only be set inphp.inicould work too—keeping it immutable once the script starts. Thoughts?kocoten1992 commentedon Mar 2, 2025
Yes, more lock down would be better in enterprise or hosting service environment. In your case, would add
ini_settodisable_functionsin php.ini work? I'm a bit worry if there are too much config to begin with..frederikmillingpytlick commentedon Mar 3, 2025
@kocoten1992 Adding
ini_settodisable_functionsisn’t a solution in my scenario. The application utilizesini_setextensively for a wide range of settings, making that approach impractical.That’s why I’m suggesting a
max_memory_limitsetting. It would maintain the flexibility ofini_setfor other configs while cappingmemory_limitchanges at runtime, offering stability without sweeping restrictions. Alternatively, makingmemory_limitonly be able to be set inphp.ini(and/or per dir) would also be a solution.I see your concern that PHP already got a lot of config options. Perhaps you'd be more inclined to the alternative solution of making
memory_limitimmutable during runtime?kocoten1992 commentedon Mar 3, 2025
I understand your problem better now, change config at runtime is fine, except when it come to resource allocation? It could be a new class of problem. You have better chance discuss on php mailing list and propose a solution for your problem (web interface at https://externals.io/).
iluuu1994 commentedon Mar 3, 2025
It's a valid strategy to keep memory limit as low as possible, and increase it for endpoints that need it (e.g. the ones opening large files). If those endpoints are hidden behind authentication, this can potentially protect you against certain DoS attacks. Locking down
memory_limitwould break this approach.Generally, it's your own responsibility to set these values appropriately, whether globally or at runtime. If some vendor code sets it unreasonably high, IMO, this should be fixed on their part.
bukka commentedon Mar 3, 2025
Agree we should not lock memory_limit. If anything, it should be a new INI.
frederikmillingpytlick commentedon Mar 3, 2025
@iluuu1994 that's why I initially suggested a new INI
max_memory_limitto limit changes ofmemory_limitduring runtime. The default could be unlimited to ensure no breaking changes. Am I understanding correctly that you'd be open to that solution?iluuu1994 commentedon Mar 3, 2025
Sure, I wouldn't object to an upper limit.
frederikmillingpytlick commentedon Mar 7, 2025
@iluuu1994 It seems there's more support for the
max_memory_limitINI. How would you suggest I proceed? Should I attempt at creating a patch, or is an RFC the better next step?7 remaining items
Implement changes to GH-17951 according to ML discussion
Fix phpGH-17951: Addition of max_memory_limit INI
memory_limit is not always limited by max_memory_limit
Commit the actual fix for GH-17951
Merge branch 'PHP-8.5'
memory_limit is not always limited by max_memory_limit
Commit the actual fix for GH-17951