Nextcloud 23.02 OPcache interned strings buffer

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.

1 Like

In DirectAdmin i’ve now set for the specific user ‘php-fpm Global |CUSTOM2|’ :
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’ve now in DirectAdmin:

php_admin_value[opcache.save_comments] = 1

and still the buffer seems not enough …

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.

Download the zip here: OCP - Opcache Control Panel (aka Zend Optimizer+ Control Panel for PHP)#ocp #php #opcache #opcode #cache #zend #optimizerplus #optimizer+ · GitHub

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.

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: Shared Hosting Server | Tuning Guide | LiteSpeed Web Server | LiteSpeed Documentation
But that needs some work on the server I think.
I’m looking forward to NC response on my findings.


Try restarting php-fpm if you can.

See [Bug]: The OPcache interned strings buffer is nearly full · Issue #31223 · nextcloud/server · GitHub

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.

please use below config for best performance

for more info :slight_smile:
How to speed up your Laravel application with PHP OPcache? - Orkhan Alishov

nano /etc/php/7.4/fpm/conf.d/10-opcache.ini

Then at the bottom of the file add the following configuration:


systemctl restart php7.4-fpm.service

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!

Hope this helps

How does one run that in console? Also, are there characters missing due to the forum software?

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 :wink:. Put this code into a .php file inside your webroot and open it in browser to get the info.

1 Like

Thank you for clarifying. Now if only I can stop NC from redirecting when a different file is specified… ie 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:


Point your browser to the respective path.