[Bug]: Unsupported `opcache.file_cache_only`?

[solracsf]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

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?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

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]

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]

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]

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:

• Using opcache.file_cache_only disables the memory based OPcache and hence decreases performance, so in general it is right to show a recommendation.
• You know your specific setup best and whether you may follow the recommendation or not.
• Others who are probably new to the topic may be thankful for the hint that there are performance enhancements possible.

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]

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 ;)