That is nonsense as a generic recommendation, it depends on the PHP sites/applications served. 64 MiB opcache.memory_consumption is fine for Nextcloud alone, even with 16 MiB interned strings buffer. Also opcache.fast_shutdown does not exist anymore, i.e. the gist is outdated.
With opcache.validate_timestamps=0 PHP will always and immediately use cached code. Otherwise, if the last check for a particular script was more than opcache.revalidate_freq seconds ago, it first checks the timestamp of the PHP script on disk, and if it is newer than the age of the cache entry (hence if it has changed), it will re"compile" (as far this term can be used for opcode) the cache entry before handling the request. So yes, with opcache.validate_timestamps=0 you increase performance and reduce disk reads. This is perfectly fine with Nextcloud, as on NC or app upgrades it will actively evict related cache entries. The only issue with this is when you edit config.php, you need to manually evict the cache entry (e.g. via opcache-gui) or restart the PHP service, for it to take effect.
It does not set any values that can worsen performance. The only reason might be when your physical RAM is insufficient so that disk swapping is used (if enabled). But actually raising the OPcache size does not allocate this additional space immediately but only when it is really used. Also not sure how a “too” small OPcache would compare to a “sufficient” large one which otherwise triggers disk swapping on a regular basis. That should be ruled out, aside of during short peak periods, daily maintenance tasks or such.
In DirectAdmin i’ve now set for the specific user ‘php-fpm Global |CUSTOM2|’ :
php_admin_value[opcache.interned_strings_buffer]=128
php_admin_value[opcache.max_accelerated_files]=25000
php_admin_value[opcache.memory_consumption]=256
php_admin_value[opcache.save_comments] = 1
php_admin_value[opcache.revalidate_freq] = 60
and still Nextcloud reports the values are to low. I restarted php after every change.
The PHP OPcache module is not properly configured:
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 25000.
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 128.
So, nothing helps. There are 2 Wordpress sites running next to nextcloud for this user.
Well, the OPcache is in fact fully used by Nextcloud and the two WordPress instances then. If your system memory permits, try increasing the values further, else ignore the warnings, it’s performance related only and does not affect functionality.
Over 25,000 cached keys (PHP scripts) is indeed much. As mentioned, while our server with phpBB, one WordPress and Matomo uses up to 256 MiB interned strings buffer, it’s up to 5000 cached keys only. Obviously every instance is different, depending on extensions and usage.
I found a very nice tool to see what happens. ocp.php . Just put that file in the documentroot and run it with domain/ocp.php.
In my case it seems that Wordpress causes massive scripts that fill the memory space.
It shows almost everything. Below this are the numbers/counts.
The strange thing is that Nextcloud reports a full memory, while this tool shows there is still plenty space left.
The 13k screenprint I made is not accepted for unknown reasons.
I’ve experimented. Debian12, Apache, PHP8.0 and ISPconfig.
Just NC 23.02 with a user (client).
In the client php.ini I set the opcache limits.
I stopped with
opcache.memory_consumption=49152 (MB !!)
and still the memory is nearly full (98,3%) warning.
opcache.interned_strings_buffer=1024 also ‘walks full’
Conclusion 1:
With the OCP tool (added the options as described in the link comments), I found out that the memory that is evaluated with the check (also in Nextcloud) is the total serverwide . (click on the ’ Files’ tab and expand. So the settings are not used on a per/user base. With DirectAdmin it seems the same.
Conclusion 2:
Opcache just fills up all available space. It is not clear for me how specific user php.ini settings are used in the memory allocation process.
Conclusion 3:
Perhaps this Nextcloud evaluation works on a server that just Nextcloud hosts, but that seems a unique condition.
Fact is that the info that is given by ‘System’also reflects the whole server, and not the user/client space and other settings.
I think that opcache testing is not relevant in the way it is now implemented. It confuses our clients and me.
It is possible to test just the opcache used by Nextcloud. But that needs altering the code. The OCP.PHP reports all php modules in opcache with their serverpath. Like this:
/var/www/clients/client2/web7/web/3rdparty/symfony/routing/RouteCompilerInterface.php 2K
and the same thing for all other clients.
In my case the memory consumption is the sum of all ‘/var/www/clients/client2/web7/web/’ serverpath files in opcache (this is not the url). And that sum is not what is tested to result in the opcache warnings now.
edit:
The opcache is created per PHP version on the server.
If you have multiple users, they all use the same opcache that belongs to the php version they use.
The problem is also with CPanel and ISPConfig, not only DirectAdmin.
Perhaps this tool is usefull to enable opcache per user: https://docs.litespeedtech.com/products/lsws/tuning-shared/
But that needs some work on the server I think.
I’m looking forward to NC response on my findings.
That have I done. After some time (30 minutes) the cache is full again.
It is standard behavior of Opcache as stated before. There is one cache per PHP version. If that PHP version is shared with other sites, the cache is also shared.
I had the same problem on my system. The answer was very simple, but not obvious.
You have to set the opcache settings (as mentioned in the last post) in /etc/php/7.4/fpm/conf.d/10-opcache.ini or php.ini. The opcache is global and not separated for every virtualhost or php-fpm-configuration even if you can set it there and phpinfo shows different settings (they are not used)!
I removed all opcache settings from my fpm-pools and set it in php.ini. Now everything works as expected!
You cannot run this in console, since you want to measure the webserver’s PHP OPcache instance/handler and not the (empty) PHP OPcache instance built by the PHP CLI command . Put this code into a .php file inside your webroot and open it in browser to get the info.
Thank you for clarifying. Now if only I can stop NC from redirecting when a different file is specified… ie https://nc.domain.com/opcache.php still directs to …/apps/files.
Edit: a few edits in .htaccess fixed this. Can now see it.
Ah right, I forgot Nextcloud’s redirect rules (I have it in a subdirectory). You can trick it by using a known excluded directory. Create the following directory inside the Nextcloud dir and put the script inside:
For a small instance with a single server the recommended configuration is APCu for local memcache and Redis for everything else!
install APCu: debian 11 / nextcloud 23.02
sudo apt install php8.0-apcu
APCu is disabled by default on CLI which could cause issues with Nextcloud’s cron jobs. Make sure to set apc.enable_cli to 1 on /etc/php/8.0/cli/php.ini or append --define apc.enable_cli=1 to the cron job command.
re-enabled the memcache in the nextcloud config and this executes without error message:
this fix the OPcache interned strings buffer is nearly fullMemory Caching
konki
edit:
this solution was effective only at the implementation, the warning reappeared. I finally installed and configured Redis and uninstalled apcu, no more OPcache errors
I had opcache.interned_strings_bufferalready set to ugly huge numbers like 272 - and the warning came back anyway after few days. Restarting PHP-FPM service “solves” this (warning disappears) for some time, just a workaround at best.
It really doesn’t matter what (huge value) is set, the root issue - and if it’s only NC misleadingly complaining about it - must be another thing.
If you are on a shared server, or multiple websites are running, this warning is normal.
Opcache is by default shared per PHP version. You get this warning also when you have Redis activated. I’ve had 4GB Opcache that had effect for a little time.
You can try to set parameters for the Opcache, but tose have no effect. Only on serverlevel per PHP settings work is my experience.
On github you can find a little tool (php script) to see what is in the Opcache.
No, my own plain baremetal Debian/Raspberry Pi OS.
This warning keeps being annoying. For now I deciced to actively ignore it after every NC update until it magically solves itself by a fix in an update. Just a waste of time for 1,5 years now.