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.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’ve now in DirectAdmin:
php_admin_value[memory_limit]=2048M
php_admin_value[upload_max_filesize]=6G

php_admin_value[opcache.enable_cli]=1
php_admin_value[opcache.memory_consumption]=1536
php_admin_value[opcache.interned_strings_buffer]=1024
php_admin_value[opcache.max_accelerated_files]=16229
php_admin_value[opcache.save_comments] = 1
php_admin_value[opcache.revalidate_freq]=1
php_admin_value[opcache.max_wasted_percentage]=5
php_admin_value[opcache.validate_timestamps]=1
php_admin_value[opcache.revalidate_freq]=1
php_admin_value[opcache.validate_permission]=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.

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.

Hi,

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.

Hi,
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:

opcache.memory_consumption=256
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=32531
opcache.validate_timestamps=0
opcache.enable_cli=1

systemctl restart php7.4-fpm.service


2 Likes

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 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:

.well-known/acme-challenge

Point your browser to the respective path.

my settings in php 7.4 to get :white_check_mark: All checks passed :sunglasses: in overview

memory_limit = 512M
upload_max_filesize = 200M
max_execution_time = 360
post_max_size = 200M
date.timezone = Europe/Paris
opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=50000
opcache.memory_consumption=128 ou 512
opcache.save_comments=1
opcache.revalidate_freq=1
opcache.max_wasted_percentage=15
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.fast_shutdown=1
opcache.mmap_base=0x20000000
opcache.file_cache_fallback=1

add in config/config.php
‘memcache.local’ => ‘\OC\Memcache\APCu’,

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:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html#id1

sudo -u www-data php --define apc.enable_cli=1 -f /var/www/nextcloud/cron.php

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

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html#id2

Don’t forget to restart apache2/nginx, Redis and absolutely php-fmp

Nginx php8.0 debian11
sudo systemctl restart nginx php8.0-fpm

Optimization could be the subject of a topic on the forum, there are many tools that give information on the functioning of the web server, up to the database (GitHub - amnuts/opcache-gui: A clean, effective and responsive interface for Zend OPcache, PHP-FPM Process Caluculator https://pgtune.leopard.in.ua/ and many others.

Someone is in charge of it?

1 Like

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.

1 Like

Another easy way to see the currently used memory values is to navigate to

https://YOUR-NEXTCLOUD.com/ocs/v2.php/apps/serverinfo/api/v1/info

(Got the link from the bottom of the admin system page)

You have to be logged in as admin in your browser for this link to work.

Output is like this:

[...]
<interned_strings_usage>
<buffer_size>12582464</buffer_size>
<used_memory>4779120</used_memory>
<free_memory>7803344</free_memory>
<number_of_strings>75022</number_of_strings>
</interned_strings_usage>
[...]

Then refresh the page to see the changes you made in e.g:
/etc/php/7.4/apache2/conf.d/10-opcache.ini

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.