Admin documentation - possible limitations at Redis server after upgrade to Nc26

[Antreesy]

From a customer ticket, could be applied here:
https://github.com/nextcloud/documentation/blob/master/admin_manual/release_notes/upgrade_to_26.rst
https://github.com/nextcloud/documentation/blob/master/admin_manual/office/troubleshooting.rst

Problem overview

After upgrading from v24 to v26 there could appear some performance issues.

Web server - Debian12
Redis server - Debian12, redis-server v7.0.11
PHP version: 8.2

Common errors:

• /apps/files/","message":"session_start(): Failed to read session data: redis (path: tcp://[instance:port](http://instance:port)?timeout=10) at /var/ www/nextcloud/lib/private/Session/Internal.php#221"
  -Access forbidden. CSRF check failed at registration
• CSRF check not passed at file upload

Performance bottleneck when creating the redis data was suspected:

• During high-load hours (working time) upload a 1GB text-file fails
• At evening upload of 10GB file goes without problems
• It was also not possible to log out correctly in the web browser
• The command "redis-cli monitor" on the redis-server shows many requests for the user for this time.

Solution

A UFW firewall is running on the redis server. The value `net.netfilter.nf_conntrack_max" was only set to 8192, but the number of simultaneous connections ranges between 6,000 and 12,000. Default value, according to documentation should be around 65536 or higher

[joshtrichards]

Looks like another indicator of this condition could be the message nf_conntrack: table full, dropping packet appearing in the host's kernel ogs.

Do we know why the value was so low in this environment? E.g. Was this a Debian 12 thing? A UFW override? A low (<4GB) memory host/VM/Container triggering some auto configuration? Etc

the number of simultaneous connections ranges between 6,000 and 12,000.

How many peak active users are we talking about that generated that level of Redis connections being tracked in the kernel connections table?

Implied here is that behavior changed between NC24 and NC26 which triggered this value becoming a limiting factor. How confident are we about the diagnosis that our behavior changed (or is that currently just our best guess about why this low value for net.netfilter.nf_conntrack_max suddenly became an issue)?