nextcloud / server

☁️ Nextcloud server, a safe home for all your data
https://nextcloud.com
GNU Affero General Public License v3.0
26.67k stars 4k forks source link

[Bug]: Unsupported `opcache.file_cache_only`? #33325

Closed solracsf closed 1 year ago

solracsf commented 2 years ago

⚠️ This issue respects the following points: ⚠️

Bug description

Configure PHP-FPM opcache with opcache.file_cache_only=1 Nextcloud will output warnings on the Admin page.

The maximum number of OPcache keys is nearly exceeded. To assure that all scripts can be hold in cache, it is recommended to apply opcache.max_accelerated_files to your PHP configuration with a value higher than 10000.

The OPcache buffer is nearly full. To assure that all scripts can be hold in cache, it is recommended to apply opcache.memory_consumption to your PHP configuration with a value higher than 1536.

The OPcache interned strings buffer is nearly full. To assure that repeating strings can be effectively cached, it is recommended to apply opcache.interned_strings_buffer to your PHP configuration with a value higher than 96.

Full configuration:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=1536
opcache.interned_strings_buffer=96
opcache.max_accelerated_files=1048793
opcache.file_update_protection=5
opcache.validate_permission=1
opcache.validate_root=1
opcache.file_cache_only=1
opcache.file_cache=/tmp
opcache.file_cache_consistency_checks=1

@MichaIng mind to have your input here?

Steps to reproduce

  1. Configure PHP-FPM opcache with opcache.file_cache_only=1

Expected behavior

No warnings

Installation method

No response

Operating system

No response

PHP engine version

No response

Web server

No response

Database engine version

No response

Is this bug present after an update or on a fresh install?

No response

Are you using the Nextcloud Server Encryption module?

No response

What user-backends are you using?

Configuration report

No response

List of activated Apps

N/A

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

Solved removing any opcache.file_cache* configuration.

MichaIng commented 2 years ago

The recommendations of the admin panel with your settings are correct, since with file_cache_only, memory-based OPcache is disabled, breaking performance a lot, and the other settings which are checked are without effect. Can you verify e.g. via https://github.com/amnuts/opcache-gui that used memory, interned strings and cached keys are all zero?

Is /tmp a tmpfs in your case? If so, I don't really see a difference between your setup and simply skipping the file_cache, aside of that letter will use the native OPcache feature instead of some configuration-wise round trip which surely works less efficient than the intended shared memory.

opcache.file_cache is usually used to faster restore the regular shared memory OPcache e.g. after server or service restarts, or when clearing the cache after it was full. file_cache_only=1 however disables the shared memory OPcache completely. Just assure that this is what you wanted to achieve, and if so, the admin panel is correct that your setup isn't optimal from performance point of view.

solracsf commented 2 years ago

Well, in this case, these warnings are pretty intrusive. Sysadmins who enable file_cache do it for a good reason (eg. shared systems where memory based Opcache is unsuitable for some reasons) so when this is detected, Opcache setup checks should just be skipped. Otherwise, NC admins thinks this is a setup issue while it is not (again, server side perspective, not NC one).

MichaIng commented 2 years ago

Hmm, especially on a shared system I'd think that the memory based OPcache is better suited than a file based one, since user A cannot invalidate the cache of user B then, assuming that dedicated FPM pools (hence dedicated OPcache instances) are used. If it is intended that the cache is shared between all users, wouldn't it be better then to just use a single FPM pool instead of a shared file cache, so also workers can be shared more efficiently?

However, of course there are cases where it makes sense to set opcache.file_cache_only=1, which is why the option exist.

The main question is whether we generally want to give performance recommendations which are right and applicable in most cases, but of course can never be right or applicable in 100% of cases, also e.g. if system memory simply does not allow to further increase the cache. There are a lot of checks which one must ignore in certain cases, or which simply cannot be addressed in all cases, like shared hostings, containers etc. So for admins which know what they need and can do with their setup, it is expected that some notifications may need to be ignored. They are made as hints to look at for those admins which might not exactly know about every piece of their Nextcloud, webserver and PHP setup. In this particular case:

But we should at least check for opcache.file_cache_only=1 in particular and then show a dedicated recommendation (like we do with opcache.enable), instead of showing the tree recommendations about settings which have no effect in this case.

solracsf commented 2 years ago

But we should at least check for opcache.file_cache_only=1 in particular and then show a dedicated recommendation (like we do with opcache.enable), instead of showing the tree recommendations about settings which have no effect in this case.

At the very least, yes ;)

MichaIng commented 1 year ago

PR up: #35365

Jolopu commented 1 year ago

The warnings are finally gone on my shared host. But now, we got a new annoying warning:

Der OPcache mit gemeinsamem Speicher ist deaktiviert. Für eine bessere Leistung wird empfohlen, opcache.file_cache_only=0 in Ihre PHP-Konfiguration aufzunehmen und den Dateicache nur als Second Level Cache zu verwenden.

Unfortunately there is now way I can set opcache.file_cache_only on my shared host. So you just introduced a new warning, which we on shared hosts are doomed to live with.

Jolopu commented 1 year ago

I asked my hosting provider to change the setting. His answer might be of interest to you:

Der Parameter kann leider Benutzerseitig nicht verändert werden. Das können wir nur über den Support umsetzen, da dies direkt in der Systemkonfiguration gesetzt werden muss.

Ich möchte hier vorher aber auf eine Sache hinweisen. Der Opcache lagert die Daten dann im SHM also im shared Memory ab, dieser ist per se nicht geschützt und es kann sein das andere Benutzer des Servers diese Daten mittels einiger Tricks auslesen können. Es gibt zwar einige Parameter welche das etwas absichern, aber eine 100%ige Lösung ist das nicht. Aus dem Grund ist der SHM Teil des Opcache erstmal per Standard abgeschaltet.

Einen starken Einfluss auf die Performance im Nextcloud dürfte das nicht unbedingt bringen (Installations- und Verwendungsabhängig), nur prüfen die Entwickler das nicht richtig und gehen automatisch davon aus das SHM aktiv ist, wodurch es dann zu diesen unschönen Meldungen kommt.

MichaIng commented 1 year ago

Good point about other users on the same shared hosting being able to view ones PHP files. It is at least true that a single OPcache is shared across all pools of a PHP-FPM master process. So if your hosting provider runs e.g. a single master process with 1 pool per user (or even a single pool for all users), then it makes sense. Then other users would also be easily able to clear your cache and the other way round 😄. If there is an own PHP-FPM instance per user, then not sure, at least then it is not trivially possible.

However, the recommendation stays correct: For best performance, the RAM based OPcache should be used. It is perfectly fine if not all recommendations/setup hints can be address in every case. One should not feel disturbed by them if you do understand the meaning and that it does not apply/cannot be applied in your case.

Jolopu commented 1 month ago

Would be nice if this warning could be disabled if nothing can be done about it on a shared host and it doesn't apply anyway.

MichaIng commented 1 month ago

Why? Your know now that you shared hosting provider has a sub optimal PHP configuration performance-wise, probably to safe on hardware (RAM). Good to know IMO, so you can ask him to change it, or change the provider, or ignore the information.

Do not feel annoyed by a Nextcloud admin panel warning. There are many which do apply in some cases, not in others. I have 3 resp. 5 warnings on my instances, which I know are not relevant in these particular cases, but good to know about in general. And these are instances where I have full control of the system, PHP setup etc. On a shared hosting provider, I would be pretty surprised to not see a bunch of warnings, at least as long as it does not advertise to support Nextcloud well in particular.