セッションが古いですか？SSLセッションで新しいセッションを割り当てられませんでした

インストール
1

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.

2

また発生しました。/etc/nginx/conf.d/discourse.conf で ssl_session_timeout が 1d に設定されていることがわかりました。これは、デフォルト の 10m から変更されたのはなぜですか？

3

私もログでそれらを確認しています。数は多くありませんが、発生しています。その設定変更に関する情報は見つかりましたか、それともご自身でより短い時間枠に戻しましたか？

4

キャッシュサイズを1MBから40MB程度に引き上げることができるかもしれません。私の知る限り、タイムアウトと連動させる必要があり、片方だけ引き上げました。

「いいね！」 2
5

なるほど。キャッシュサイズを変更することは、誰かのリストに載りましたか？