durable-streams-rust: lazy stream-file fd management (1 fd per live stream ≈ nofile ceiling at 1M streams)

オープン
#4,706 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust

調査の方向性

まず create/recover で Shared.file がどのように開かれるかを追跡し、次に issue で指定されているパスを読みます: resolve_range、ap.file、compaction swap。アイドル時のクローズ/再オープンという選択肢を、Arc の refcount の動作および関連する issue と比較してから、アプローチを選択してください。完了の条件は、in-flight の読み取りの安全性を保ったまま、実行中のストリームごとに 1 つのオープン fd を必要としなくなることです。

索引モデルが issue の本文から書いたものです。

説明

The WAL/data design holds one open fd per live stream for its lifetime (Shared.file, opened at create/recover). Measured on the wal-1m-diag run (2026-07-13): 1,005,724 fds at 1M streams — 96% of the default container hard limit (1,048,576). It was NOT the cause of the 1M throughput wall (that was checkpoint writeback on one device — fixed by --stream-lanes, #4705), but it is a hard scale ceiling just above 1M streams: the next stream open or socket accept hits EMFILE.

Options:

  • Idle-close sweeper + on-demand reopen (Shared.file: Option<Arc<File>>), bounded by an LRU-ish cap: hot streams keep fds, idle ones close. Touches the read path (resolve_range clones the Arc), append path (ap.file), and compaction swap — the Arc refcount model makes eviction safe (in-flight sendfile keeps the fd alive).
  • Deployment mitigation meanwhile: raise LimitNOFILE on the node/containerd.

Related: #4695 (log-structured store) would remove per-stream files entirely; #4705 measured the residual per-file writeback slope (374k @100k → 212k @1M on 3 lanes).

主要言語
TypeScript
スター
10.4k
フォーク
399
PR マージ指標
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

electric-sql/electric のほかの issue

electric-sql/electric の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。