increase opcache buffer to 64

[szaimen]

Close #772

Signed-off-by: szaimen [email protected]

[szaimen]

@MichaIng does this look good?

[Zoey2936]

I think it could also directly set to 64, then the chance to hit this limit would be much smaller

[szaimen]

I think it could also directly set to 64, then the chance to hit this limit would be much smaller

fine by me 👍

[MichaIng]

IMO 64 MiB for interned strings buffer is too much. It is reserved from the 128 MiB overall default OPcache size and 64 MiB for PHP scripts is rare but possible with Nextcloud only, hence this can cause the other limit to be reached. 64 MiB strings should only be possible with temporary scripts and hence temporary strings which are not cleared automatically once a new temporary script got created, I guess. It's difficult to analyse since there is no way (I'm aware of) to list the actually stored strings.

I'm not sure how to deal with this best: If only Nextcloud is used, more than 16 MiB strings buffer should never be reasonable, but with other applications using the same pool it can be (along with a larger overall cache size). So not sure whether hiding the warning in general for >16 MiB is a good idea. For VM/Docker/Snap/AIO however we know that it's Nextcloud only, just backend internally I'm not aware of a method to know this (which could be used for the checks to show or not show the warning).

It would be really great to find out which apps/use cases cause this high strings buffer usage, but so far I couldn't find a clear match among the reports.

I'm open for suggestions, in a new/related issue on server, of course.

[szaimen]

Thanks for the answer! So even 32 is not reasonable?

[MichaIng]

Hard to say absolute. If really an app contains that large amount of strings in it's code/GUI, it can be reasonable. But I cannot imaging that any app does so.

Would be great to be able to look into the strings buffer and see which strings from which scripts it contains.

I'll have a look into Nextcloud data, to probably find a location where apps can store temporary data/scripts. Strings from the database are AFAIK not hold in that buffer (like such contained in the generated HTML documents.

Some reading: https://www.phpinternalsbook.com/php7/internal_types/strings/zend_strings.html#interned-strings

[szaimen]

Okay, so I would reduce it to 16 again and ask people in the future to fist debug it?

[MichaIng]

I'd suggest to use 32 MiB for the following reason:

• Nextcloud is able to use max 64 MiB of the regular OPcache. I tested this once with installing and browsing the GUI of literally all available apps, and hit close to 64 MiB.
• So 32 MiB for interned strings is safe to use without a risk to hit the default overall OPcache size of 128 MiB, when only Nextcloud is used.

I'll also suggest this for nextcloud/server#32902.

I btw verified that increasing the interned strings buffer, even that it is reserved from the overall OPcache memory, does not increase the system memory usage.

[szaimen]

thanks! will do so :)