In our case the message is gone by changing /usr/local/directadmin/custombuild/custom/opcache/opcache.ini
| Enabled | Yes |
| Cache full | No |
| Restart pending | No |
| Restart in progress | No |
After this, rebuild opcache.
Perhaps this helps.
How? Did you stare at it for 1.5 years?
Sorry could not help it 
Yes I did. I did not try to do what the message says after every NC update for 1,5 years. Now I try to just stare at your profile for another 1,5 years. 
So this seems to basically just silence this message completely.
Are there any downsides to this? What if the cache will really be filled some day, should Nextcloud be aware of that?
For now it looks like a neat workaround. Will look into that one, thank you.
We have Redis enabled on the server. Each user has a unique Redis container that can hold up to 15 databases:
‘memcache.local’ => ‘\OC\Memcache\Redis’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘redis’ =>
array (
‘host’ => ‘/home/username/.redis/redis.sock’,
‘port’ => 0,
‘dbindex’ => 3,
‘timeout’ => 1.5,
),
That works fine.
The Opcache is not needed as far as I know. But to answer your question: it will always be filled competely after some time and if default settings are used, it wil auto refresh contents. Have a look at PHP: Runtime Configuration - Manual to see the runtime configuration options for Opcache.
That’s exactly what I use too (REDIS). How to get rid of the OPcache stuff so this warning is a thing of the past?
I only have a /etc/php/8.1/fpm/conf.d/10-opcache.ini and that looks different and I know nothing bout rebuilding.
Server tuning — Nextcloud latest Administration Manual latest documentation states it’s basically a good thing.
I think I will continue to just ignore this dumb useless warning still seen on NC v25.0.5.1.
Try using php8.0-fcgi instead of fpm. Resolved issues for us after we updated to 25.0.5
What exactly do you mean when you say “using php8.0-fcgi instead”?
FPM is short for FastCGI Process Manager and the corresponding package is called php-fpm, respectively php8.0-fpm in most Linux distributions. There is no php-fcgi package, at least not in the distributions I know.
Sorry if it was a bit unclear. We have a GUI where we can change PHP Versions. Those include a package called php8.0-fpm as well as php8.0-fcgi. The correct package name in the distros would just be php8.0-cgi
what is the equivalent setting of opcache.interned_strings_buffer when using nginx?
should be the same i guess. you should find it in the php.ini of your nginx
So what’s wrong with NC constantly hammering this message and thinking I am using Zend OPcache. I use REDIS and in my /etc/php/8.2/fpm/php.ini the ;opcache.enable=1 is set (so basically I am not using the OPcache at all!). Maybe I’m configuring the wrong place all the time which is why a change of value of
; The amount of memory for interned strings in Mbytes.
;opcache.interned_strings_buffer=8
did not change anything?
I’m using Nginx and PHP8.2-FPM on a Debian host. php -i | grep opcache gives (among other lines)
Zend OPcache
Opcode Caching => Disabled
Optimization => Disabled
SHM Cache => Enabled
File Cache => Disabled
JIT => Not Available
Startup Failed => Opcode Caching is disabled for CLI
Directive => Local Value => Master Value
[...]
opcache.enable => On => On
So where is this configured? I checked all php.ini files, none of them have opcache.enable=1 active. So do I use the Zend OPcache now or don’t I?
Looking for an answer to this (exact config location) will hopefully also allow me to decide if I should (continue to) use the Zend OPcache and then configure opcache.interned_strings_buffer correctly.
No other website and almost the same stats
Array
(
[opcache_enabled] => 1
[cache_full] =>
[restart_pending] =>
[restart_in_progress] =>
[memory_usage] => Array
(
[used_memory] => 70240896
[free_memory] => 63961512
[wasted_memory] => 15320
[current_wasted_percentage] => 0.011414289474487
)
[interned_strings_usage] => Array
(
[buffer_size] => 8388608
[used_memory] => 8388592
[free_memory] => 16
[number_of_strings] => 96216
)
[opcache_statistics] => Array
(
[num_cached_scripts] => 3369
[num_cached_keys] => 6443
[max_cached_keys] => 16229
[hits] => 7506050
[start_time] => 1699863784
[last_restart_time] => 0
[oom_restarts] => 0
[hash_restarts] => 0
[manual_restarts] => 0
[misses] => 3646
[blacklist_misses] => 0
[blacklist_miss_ratio] => 0
[opcache_hit_rate] => 99.95144943284
)
[jit] => Array
(
[enabled] =>
[on] =>
[kind] => 0
[opt_level] => 0
[opt_flags] => 0
[buffer_size] => 0
[buffer_free] => 0
)
)
This is a barebones NextCloud install with just one add-on (passwords) not within the suggested apps. And encryption enabled.
2 Users, none of which is online, on a 2 Cores, 2 Threads Intel® Xeon® CPU, 2 GB RAM, 15 GB On-Board SSD Drive with ZFS
I think it is pretty “standard” for NextCloud as it appears?
Might this make the difference? Do you mean server-side or client-side encryption?
Could be, although as per DOC, encryption only increases physical storage by about 30%, not the php runtime memory. This should not affect any script’s allocated memory.
However, depending on if @eBug also has encrypt on, it might be the underlying issue still.
The script’s allocated memory is responsible for the regular OPcache memory usage, but the issue here is about the interned strings buffer. To be true, I am not sure which strings at which stage of processing are stored in this buffer, but since it can grow (in rare cases) far beyond the size of the scripts themselves, it cannot be only hardcoded strings in code, but likely variable values and probably chunks of the generated HTML documents or even other/POST data moved around internally. The problem is that there is no way to see what is actually stored in this cache, compared to the list of scripts you can get for the regular OPcache memory.
Server-side encryption implies sending around file hashes (?). I lack insights, but its just an idea what might cause the difference here, as we were never able to identify specific apps causing the increased/unlimited interned strings buffer usage.
But btw, in your case 8 MiB usage is not that much. Still more than I see on my Nextcloud instances, but the cases I am wondering about is those where this usage grows unlimited, regardless how large you set the buffer. In your case, try to increase it to 16 MiB and see whether this solves it sustainably.
After upgrading to NC28, I also have the OPcache interned strings buffer error. I am not as experienced as others in the thread who have commented and am having trouble following the thread. Can someone help me? Is there a fix to this error or do we just ignore it? It is my own bare metal server with lots and lots of RAM. Merci.
The option is enabled in php.ini not nginx…