Hi Christoph,
many thanks for your reply.
If interned_string_buffer is supposed to be a power of two, does
"opcache_get_status" then report wrong values, or is it a bug in PHP
that indeed values between powers of two can be applied (as reported
back by "opcache_get_status")? It is however good to know that powers of
two at least seem to be expected, so that it shouldn't be tried to apply
a different one.
Which kind of strings are actually stored. Is it only hardcoded
variables in the PHP code of type string only, or also variable strings
like outputs of a databases queries, and/or can it be also parts of the
code/syntax itself? And is it exclusively handled internally or is there
a way that scripts can manually add strings?
I couldn't observe any issues with the full strings buffer indeed, all I
was wondering is why it is always full. I guess when returned database
values are stored in variables and then land in the strings buffer, this
would be an explanation, e.g. in a forum or blog with lots of posts when
whole post texts are stored in the strings buffer. I guess in this case
there wouldn't be a reasonable way to keep all those cached and we'd
need to find a size with doesn't fill up too much RAM of the whole
server (prevent regular swapping) and allow/rely on OPcache to
internally keep the most requested strings/post in the buffer after a while.
Am 02.12.2021 um 14:49 schrieb Christoph M. Becker:
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
