Configure PHP memory_limit via environment variable #568
Conversation
rcdailey
force-pushed
the
configurable-memory-limit
branch
2 times, most recently
from
5b0db6b to
d7f4888
Compare
A new Docker environment variable named `PHP_MEMORY_LIMIT` has been introduced which allows the PHP `memory_limit` setting to be controlled without mounting any volumes from the host. The default memory limit is still `512M` if this variable is not specified. Signed-off-by: Robert Dailey <[email protected]>
rcdailey
force-pushed
the
configurable-memory-limit
branch
from
d7f4888 to
f988290
Compare
|
@J0WI I saw you posted on the php library github page about this. Seems like you'd prefer the generic upstream solution, which I agree with, but my concern is that may not happen for a long time. Would you be against this as a stopgap solution for now? Really all I'm doing here is allowing an existing override of a specific PHP setting to be configurable from outside of the Dockerfile. Thoughts? |
|
I'd prefer to use upstream recommendations: https://hub.docker.com/_/php#example Btw. why do you need to change the |
My understanding is that the upstream instructions are for downstream Dockerfiles. But they don't really care how you build the Again: I fully agree, a flexible upstream solution would be ideal. But who knows how long we'll be waiting on that? It could be a year! Given that the "kitchen sink" solution takes time, thought, design, etc. I think this stop-gap solution is an ideal for now. Memory limit in PHP is arguably the most common setting people want to specify when configuring the Nextcloud instance.
I have Nextcloud installed in my home lab. I do not manage this for a business or anything. I literally have this thing running on my Intel NUC. The only 2 users using this thing are me and my wife, so we can each store our own files and family photos. So no, I don't want to do any load balancing or multi-instance set up. It's overkill and complex for my use case. The reason I need to bump the memory limit is two fold:
I don't think there's anything wrong with increasing the memory available to Nextcloud. This is a simple problem that needs a simple solution; not some over complicated multi-instance setup that's impractical for most homelab users. |
|
@tilosp thoughts? |
|
Having used this change for a few days now, I think this isn't working 100%. And when I say it isn't working, I mean that even the original change, which forces memory limit to 512 via
So really it's become increasingly unclear to me where one should configure PHP settings. I think the fact that you see them all over the place, as shown above, doesn't help. There's no clear, self-evident method of specifying some of these basic settings. I also have not found any official documentation on this. And sadly google search results on this issue are all over the place. The way you configure Nextcloud & PHP change drastically depending on how you are installing it, it seems. So you can't tell if certain recommendations will work with the docker container or not. At this point, I'm not sure if I should decline my PR, or try to make some sense of this and correct the problem. Would love some help from the developers. I'd love to help make a useful change here to improve the issue, so let me know if I can do anything to help. I've hit a wall on trying to figure this out myself. |
|
|
|
Unfortunately that link doesn't explain the precedence of these files, but with some searching I found this. If that's correct, then using So maybe we have a much bigger issue here: Inability to override PHP settings. Granted, I have never done PHP development before, so it could very well be there just needs to be more documentation. What is the official way to override PHP settings via the docker container? |
|
Looking further, I see this comment: nextcloud/server#4769 (comment) Basically they say not to modify Perhaps now we've come full circle. Looks like this isn't going to be solved by asking the upstream PHP image maintainers to add support for this, because even if they did, those PHP settings would be overridden by Nextcloud's So instead, I think this Docker image needs a specialized solution to modifying these files post-upgrade path. After an upgrade, apply user-specified PHP settings that overwrite the default ones that Nextcloud inserts into those files. |
|
Thanks for sharing your analysis. |
|
I guess it's a duplicate if you prefer the solution to be within the server project itself. However, there's still some (IMHO better) solutions that make things more docker-friendly, such as environment variables that result in those files being modified programmatically by the entrypoint script. My immediate concern is that issue has been open since 2016. 2 years, no fix. Will it be another 2 years? Could get a working docker-only solution in the meantime, right? |
|
@J0WI Hey, just following up. It seems you've hit a dead end on convincing the PHP library developers. Given that, I think we have two choices:
The long-term, most correct option is probably the first one. However, it's also the most difficult. Because they probably have those settings there for a good reason. Given that, and the short-term demand for configurability of memory limit by many users over the past few years, I recommend the second option as, at the very least, a stopgap solution until the first solution can be implemented. At this point, this issue has slowed down, but I want to work on a solution to this problem with urgency if possible. I'm willing to contribute any changes needed. Who's doing the work isn't the issue here. I think it's just getting the developers engaged and in agreement on the ideal short-term and long-term solutions. I'm not able to contribute any meaningful implementation to support this without it being rejected at this point. Can we come to a consensus on this issue so I can stop manually building Nextcloud docker images from forks? |
|
+1 for fixing this upstream. |
|
@J0WI for option two, I'd probably use a primitive approach where I grep the memory limit value in the existing .htaccess and user.ini files to modify it. Another option is to replace those two files with built in versions that have those settings removed and instead either require users to mount their own php.ini or define a system to procedurally generate it based on environment variables. I'm open to other ideas. |
|
Modifying these files will cause the integrity check to fail: |
|
I've modified them locally and haven't run into issues. What am I missing? |
|
You may need to trigger a rescan: https://docs.nextcloud.com/server/15/admin_manual/issues/code_signing.html#rescans |
|
I haven't done any manual scans, so maybe that's why? I did remove the settings in my fork of Nextcloud server and had no errors upgrading from 15.0.0 to 15.0.2 |
|
nextcloud/server#13990 (comment): If you are using the Apache variant, you can just insert a custom |
|
@J0WI Looks like we can close this in favor of nextcloud/server#14430 |
2 participants
A new Docker environment variable named
PHP_MEMORY_LIMIThas been introducedwhich allows the PHP
memory_limitsetting to be controlled without mountingany volumes from the host. The default memory limit is still
512Mif thisvariable is not specified.
Tested on 14.0 apache.