Re: Questions about OPcache interned strings buffer

On 28.11.2021 at 03:44, Micha wrote:

> I have two questions regarding the OPcache interned strings bugger, I
> hope this mailing list is the right place to ask them, else feel free to
> redirect me to a more fitting place.
>
> 1. What is the logic behind the assigned strings buffer size and the
> actually usable size? When using powers of 2, it seems to be exactly 75%
> of it being usable, but for values between powers of 2, the usable
> buffer size seems to increase by exactly what was added to the setting,
> so that the used percentage increases until the next power of 2 is
> reached. So basically it is possible that an increase of the settings
> value leads to a decrease of the actually usable strings buffer. I'm
> just wondering about what the remaining <=25% are used for, whether
> using a power of 2 is preferable, or the opposite to have a batter
> ratio. To avoid confusion it may be reasonable to add the <=25% always
> to the usage statistics output, so that setting and statistics match.
> Also Asked on stackoverflow:
> https://stackoverflow.com/questions/67853338/opcache-interned-strings-buffer-size-lower-than-opcache-interned-strings-buffer

First, interned_string_buffer is indeed supposed to be a power of
two[1].  Then it is important to understand that the HashTable which
stores references to the actual strings, is placed at the beginning of
the interned string buffer, so the reported buffer_size is the size of
the actual string buffer, i.e. always smaller than was has been set as
interned_string_buffer.

That should be documented in the PHP manual.

> 2. I have a PHP8.1 instance where I can increase the interned strings
> buffer size as much as I want, it is always nearly fully used based on
> the statistics. Currently it's 256 MiB assigned, 100% used with 512 MiB
> overall OPcache size ~90% used. This doesn't look reasonable, as the
> interned strings buffer is also meant to reduce the actual OPcache usage
> (? bundling strings),

No.  The interned string buffer is not meant to reduce the general
OPcache SHM size, but rather to avoid re-allocating strings for each
request (which would slow down the processing).

> so it looks wrong that it is used with more MiB
> than the remaining OPcache. Or is it somehow expected that every smaller
> and larger fraction is a string is stored in the interned strings buffer
> as long as it is available, so that it basically always fills up? If so,
> how can one estimate a good size for ones individual instance?

Hard to say.  You need to try, and settle on some acceptable value.
Note that a full interned string buffer won't stop scripts from
executing; they may just run a bit slower.

[1]
<https://github.com/php/php-src/blob/php-7.4.26/ext/opcache/ZendAccelerator.c#L2599>

--
Christoph M. Becker