Misskey: アイドル状態の接続がPostgreSQLに大量に残る

[CookieRamen]

💡 Summary

PostgreSQLの接続が大量に生えて、idle状態の接続が大量に残る

2クラスタ x 2ノードで運用しているが、3リージョンすべてでアイドル接続が100~200ぐらいになる

もしかしたらioだけの問題かもしれない

🙂 Expected Behavior

処理をするときに接続が生えて処理が終わったら切断される

☹️ Actual Behavior

処理が完了しても(Misskeyを起動するだけで大量にコネクションが生える)接続が切断されず、idle状態で大量に残る

📝 Steps to Reproduce

1.
2.
3.

📌 Environment

v12.47.1
Misskey.io

[mei23]

DB接続は1プロセスあたり最大10接続で処理完了後も接続は保持されます、接続は10秒間アイドルだったら切断されます。
基本的に、正常にこの挙動で動作しています。

常にアイドルがある用に見えるのは・・・

• Misskeyを1つ上げると、MasterとWorkerプロセスが1つずつ上がります。
• Master/Workerはそれぞれで5秒毎にMetaを取得するため、各プロセスからのDB接続は常に1つは存在することになります。
• Workerはほぼすべての処理を担当しますが、投稿/TL取得/リモート投稿 どの操作でも発生した瞬間にはほぼDB接続を10接続使用します。
• そこそこ連合があるとそれだけで1秒に1回くらいはリモートから投稿が来るので
  これを例えば10個でラウンドロビンして回していたとしても、10秒のタイムアウト期間内に必ず1つは10接続使用する処理が動くことになります。
• なので、結果的にMisskeyを1つ上げると (Master x 1 + Worker x 10) = 11 程度のDB接続が最低存在するという状態になります。

だからです。

なお、最大接続数とアイドルタイムアウトはconfigで制御出来ます。
(最終的に上がるMisskeyの総数 x 11~20程度のDB接続を出来るようにしておくのが最高のパフォーマンスと思うので あえて制限する理由はないと思いますが)

db:
  extra:
    max: 10
    idleTimeoutMillis: 10000