Probleme mit veralteten Sitzungen? Konnte keine neue Sitzung in der SSL-Sitzung zuweisen.

I’m not sure what’s up here; it might be a bug. I have a couple of sites that are getting spurious errors like these:

2021/09/29 12:46:34 [alert] 11364#11364: *1226080 could not allocate new session in SSL session shared cache "SSL" while SSL handshaking, client: x.x.42.250, server: 0.0.0.0:443

One one of them I contrived to increase max sessions like this:

  after_bundle_exec:
    - replace:
       filename: "/etc/nginx/nginx.conf"
       from: "  worker_connections 768;"
       to: "  worker_connections 1280;"
  after_letsencrypt:
    - replace:
       filename: "/etc/nginx/letsencrypt.conf"
       from: "  worker_connections 768;"
       to: "  worker_connections 1280;"

I thought that it had fixed it (didn’t see any such errors the next day), but now I’m seeing them again on that site.

This is somewhat out of my wheelhouse, but my best guess is that somehow a bunch of connections are staying active rather than being dropped and nginx is running out of sessions?

Both are standard installs and don’t have especially high traffic. One is a 4GB something on AWS the other an 8GB DO droplet (about 40K pageviews/day). I’ve got other sites with much more traffic and I don’t remember ever seeing this before, so I’m wondering if there is something new going on here.

Das ist wieder passiert. Ich sehe, dass ssl_session_timeout in /etc/nginx/conf.d/discourse.conf auf 1d gesetzt ist. Warum wurde es vom Standard von 10m geändert?

Ich sehe diese auch im Log – nicht allzu viele, aber sie tauchen auf. Haben Sie Informationen zu dieser Konfigurationsänderung gefunden oder haben Sie sie für sich selbst wieder auf einen kürzeren Zeitraum zurückgestellt?

Wir könnten die Cache-Größe wahrscheinlich von 1 MB auf etwa 40 MB erhöhen. Soweit ich weiß, muss sie mit dem Timeout zusammenhängen, und wir haben das eine erhöht, ohne das andere.

Das ergibt Sinn. Kam die Änderung der Cache-Größe auf jemandes Liste?