Addition of a max memory limit ini setting

[frederikmillingpytlick]

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

[NattyNarwhal]

The alternative might be making memory_limit no longer PHP_INI_ALL to prevent it from being set at runtime.

[frederikmillingpytlick]

The alternative might be making memory_limit no longer PHP_INI_ALL to prevent it from being set at runtime.

@NattyNarwhal that would be a great alternative and probably a lot easier to implement.

The whole idea of changing the memory_limit during runtime is absurd from a DevOps perspective.

[NattyNarwhal]

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]

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]

@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_limit is 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 a max_memory_limit setting to cap any runtime changes to memory_limit, giving us a safety net. Alternatively, locking memory_limit to only be set in php.ini could work too—keeping it immutable once the script starts. Thoughts?

[kocoten1992]

Yes, more lock down would be better in enterprise or hosting service environment. In your case, would add ini_set to disable_functions in php.ini work? I'm a bit worry if there are too much config to begin with..

[frederikmillingpytlick]

@kocoten1992 Adding ini_set to disable_functions isn’t a solution in my scenario. The application utilizes ini_set extensively for a wide range of settings, making that approach impractical.

That’s why I’m suggesting a max_memory_limit setting. It would maintain the flexibility of ini_set for other configs while capping memory_limit changes at runtime, offering stability without sweeping restrictions. Alternatively, making memory_limit only be able to be set in php.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_limit immutable during runtime?

[kocoten1992]

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]

The whole idea of changing the memory_limit during runtime is absurd from a DevOps perspective.

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_limit would 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]

Agree we should not lock memory_limit. If anything, it should be a new INI.

[frederikmillingpytlick]

@iluuu1994 that's why I initially suggested a new INI max_memory_limit to limit changes of memory_limit during runtime. The default could be unlimited to ensure no breaking changes. Am I understanding correctly that you'd be open to that solution?

[iluuu1994]

Sure, I wouldn't object to an upper limit.

[frederikmillingpytlick]

Sure, I wouldn't object to an upper limit.

@iluuu1994 It seems there's more support for the max_memory_limit INI. How would you suggest I proceed? Should I attempt at creating a patch, or is an RFC the better next step?

[iluuu1994]

@frederikmillingpytlick This doesn't necessarily need an RFC. If you want, you can create a patch and then send an email to the internals mailing list. If you're not interested in implementing it yourself, you can ask for help in your email to the list. If somebody on the list were to object, you can create a short RFC.

[frederikmillingpytlick]

@iluuu1994 I'm in the middle of fiddling with a patch for it and came up with a thought.

What do you think about adjusting the value to the max allowed in case it's above the allowed value?

Code example:
php.ini:

memory_limit = 128M
max_memory_limit = 256M

PHP code:

<?php

echo ini_get('memory_limit'); // Output: 128M

ini_set('memory_limit', '257M'); // PHP Warning: memory_limit (currently: 134217728 bytes) cannot exceed max_memory_limit (268435456 bytes). Attempting to raise memory_limit up to max_memory_limit.
                                 // Set's memory_limit to max allowed value (256M)

echo ini_get('memory_limit'); // Output: 256M

[iluuu1994]

Setting the value above what is allowed should error and not change the value. We actually already do that when you're trying to set memory_limit to a value that is lower than the currently used memory. I would expect something similar.

php-src/main/main.c

Lines 325 to 334 in a14301b

	if (zend_set_memory_limit(value) == FAILURE) {
	/* When the memory limit is reset to the original level during deactivation, we may be
	* using more memory than the original limit while shutdown is still in progress.
	* Ignore a failure for now, and set the memory limit when the memory manager has been
	* shut down and the minimal amount of memory is used. */
	if (stage != ZEND_INI_STAGE_DEACTIVATE) {
	zend_error(E_WARNING, "Failed to set memory limit to %zd bytes (Current memory usage is %zd bytes)", value, zend_memory_usage(true));
	return FAILURE;
	}
	}

Importantly, max_memory_limit should not be expandable at runtime, for obvious reasons. I don't have strong opinions on whether the user should be allowed to lower it. This might make sense in some scenarios.