kakkokari-gtyih
commented
1 month ago 日本語訳
一部のメモリー・キャッシュにはキャッシュ削除のポリシーが存在せず、アクティブなプロセスごとに何百万ものエントリーを含むまでに膨れ上がる可能性がある これは単に非効率的だというだけでなく、長い時間をかけてゆっくりと進行するメモリリークの原因ともなりうる（→ https://github.com/misskey-dev/misskey/issues/10984 ）
特に、これらのキャッシュには削除までの時間としてInfinityが指定されている
Userオブジェクト（このキャッシュは、異なるキーでさらに4回複製される）- 公開鍵（このキャッシュも別のキーで複製される）
- クライアント・アプリのメタデータ
解決策として、すべての"永続的な"キャッシュに対して、合理的なTTLを定義することを提案する。さらに、いくつかのキャッシュには、エントリーの最大数を指定できるようにするべき。そのサイズを超えると、最も古いエントリーが削除されるという仕組み。この後者の変更は、公開鍵とクライアント・アプリのキャッシュに最も効果的だろう。
warriordog
💡 Summary
Several memory caches do not have an eviction policy and can grow to contain millions of entries per active process. This is highly inefficient and is a partial cause of the slow memory leak that affects some instances. In particular, these caches have an infinite eviction time:
As a solution, caches should define a maximum capacity and reasonable eviction time. If the capacity is exceeded, then the oldest (least recently used) entry should be evicted to make room. This will prevent caches from growing indefinitely while still ensuring a high cache hit rate.
This bug was first discovered in the Sharkey fork, but exists in Misskey as well. For additional details, see Sharkey issue #600 and Sharkey MR #580.
Related to #14311.
🥰 Expected Behavior
Caches should have a limited size and reasonable eviction method to prevent infinite memory usage.
🤬 Actual Behavior
Memory caches are unbounded and consume infinite server memory.
📝 Steps to Reproduce
Run a federated instance for an extended period of time and observe memory usage. Background memory will increase indefinitely as caches are filled with remote users, public keys, and other data.
💻 Frontend Environment
🛰 Backend Environment (for server admin)
Do you want to address this bug yourself?