容量とリソースモデル
ThreadCells は、コーディングエージェントの作業が異なる時点でホストの異なる部分に負荷をかけるため、容量を分離しています。モデルターンはプロバイダー容量を消費し、割り当てられたコーディングコンテキストはモデルがアイドル中もアクティブなままであり、ビルドはモデル出力が停止した後にマシンを飽和させることがあります。
すべての数値をまとめて増やしても、通常は速くなりません。モデルクォータの競合、メモリー圧迫、ディスクの負荷、同じ CPU を奪い合う高価な複数ビルドを引き起こす可能性があります。
4つの上限
常駐スーパーバイザー
常駐スロットは、委任とコールバックをまたいで利用可能であり続ける必要があるトップレベルのスーパーバイザーまたはオーナーセッションを保持します。ワーカーの結果を待っている間も常駐容量を消費します。
これは、アイドルに見えるスーパーバイザーを終了すると、ミッションを統合する責任を持つコンテキストを失うため、分離されています。
プロバイダー実行
プロバイダー実行スロットは、モデル/プロバイダーがターンを積極的に生成している間に使われます。関連する制約は、プロバイダーの同時実行数、ネットワーク活動、プロセス数、場合によってはメモリーです。
プロンプトで待機するエージェントに、プロバイダー実行スロットは必要ありません。
作業コンテキスト
Work スロットは、現在範囲を限定したコンテキストを所有する委任ワーカーまたはレビュアーを表します。モデルターンの間に待機している間も、管理対象ワークツリーと書き込み権限を保持することがあります。
トップレベルのセッションルートは Work 容量ではなく常駐容量を消費します。常駐する委任された子は Work 容量を消費します。
高負荷実行
Heavy スロットは、プロダクションビルド、Chromium 実行、大規模テストスイート、リポジトリー全体のスキャンなど、ホスト負荷の高い作業用です。高負荷の受け入れにより、CPU、メモリー、I/O の余裕を保護します。
対象となるコマンドには、正規の高負荷ランナーを使用してください。通常の小さなテストとファイル検査には Heavy スロットは不要です。
既定の開始点
パッケージの 5 resident / 3 provider / 2 Work / 1 Heavy 設定は、保守的な小規模ホストの開始点であり、ベンチマークや固定の製品上限ではありません。
許容範囲は、常駐スロットが2～50、その他の各上限が1～50です。値はランタイムデータベースに永続化され、サーバーを再起動せずに反映されます。
自分のマシンでは何を設定すべきか
控えめに開始し、メモリー/ディスク圧迫とキューイングを観察してから、1度に1つの上限を変更してください。次の例は形を示すものであり、性能保証ではありません。
| ホスト例 | 常駐 | プロバイダー | Work | Heavy | 理由 |
|---|---|---|---|---|---|
| 小規模 VPS | 2 | 1 | 1 | 1 | スーパーバイザー1つと範囲を限定した子1つ。高価な作業は直列化します。 |
| 開発者ワークステーション | 5 | 3 | 2 | 1 | ビルドを直列化したまま、有用な並列モデルターンを確保します。 |
| 大規模共有ホスト | 8 | 5 | 4 | 2 | より多くの常駐ミッションとワーカーを、2つの高負荷タスクに対する計測済み余裕とともに実行します。 |
上限を増やす前に、実際に進行を妨げているキューを確認してください。
- Provider が満杯で CPU がアイドル: クォータが許すなら Provider スロットをもう1つ検討します。
- Work が満杯でプロバイダー容量がアイドル: 完了して確認応答済みの子を退役させるか、慎重に Work を上げます。
- ビルド中に Heavy が満杯: 2つ目の Heavy スロットが役立つのは、CPU、RAM、ディスクが同時ビルドを支えられる場合だけです。
- Resident が満杯: 完了したトップレベルセッションを閉じます。上限を上げるだけで放棄されたスーパーバイザーを隠さないでください。
メモリーとディスク圧迫
ThreadCells は、設定済みカウントとともにホストの圧迫を監視します。多数のネイティブ CLI、tmux ペイン、ブラウザープロセス、ワークツリー、ビルドキャッシュ、ログは、それらを作成した短いプロバイダータ―ンより長く残ることがあります。
ディスク状態には正確な閾値を使います。
- GREEN: 使用率70%未満。
- YELLOW: 70%から85%未満。
- RED: 85%から92%未満。
- CRITICAL: 92%以上。集約受け入れは RED のままで、
DISK_CRITICAL理由を含みます。一方、ディスク固有の投影は CRITICAL と報告します。
YELLOW は増加を調査して Housekeeping を計画する合図です。RED はリスクのある新しい作業を拒否し、復旧に安全なクリーンアップを受け入れることができます。不明な状態はフェイルクローズします。ThreadCells は読み取れないファイルシステムが正常だと仮定しません。
すでに常駐しているオーナーゲート状態のワークフローに対する明示的な Workflow Composer の決定は、ディスクのみが原因の RED でも限定的な復旧経路になります。通常の Provider 容量は使用しますが、Work コンテキストは作成しません。メモリ、PSI、不明または複合的な RED は引き続きフェイルクローズし、永続ターンは転送再試行を消費せずにリソース復旧の待機理由を表示します。
削減後のドレイン
上限を下げても、アクティブな作業が強制終了されることはありません。現在の使用量が新しい値を上回る場合、そのカテゴリは draining になり、アクティブ使用量が上限内に収まるまで新たな受け入れを拒否します。
例: 子が3つアクティブな間に Work を4から2へ変更すると、3つすべては実行を続けます。子が完了して退役するにつれ、使用量が2以下に達するまで代替は受け入れられません。
高負荷インベントリーは削減後もアクティブなより大きい番号のスロットを数え続けるため、上限変更で高価なプロセスを隠すことはできません。
容量が解放されるとき
- アクティブなモデルターンが終わると、プロバイダー容量が解放されます。
- 登録済み高負荷コマンドが終了すると、Heavy 容量が解放されます。
- 委任コンテキストが安全に退役した後にのみ、Work 容量が解放されます。
- トップレベルのスーパーバイザー/オーナーセッションが閉じると、常駐容量が解放されます。
完了した子の結果は、リソース退役前に記録、配信、組み込み、確認応答されなければなりません。ランタイム容量が解放された後も履歴は残ります。
受け入れは起動と継続の境界で再確認されます。キューに入ったプロバイダータ―ンは、プロバイダースロットが利用可能になると開始します。プロバイダー完了で解放されるのはプロバイダー実行容量だけです。開いているワークフローを閉じたり、コールバックを破棄したり、永続的な作業をまだ所有する委任 Work コンテキストを解放したりはしません。
設定と監視
現在の使用量、上限、推奨、ドレイン状態には Settings → Orchestration Capacity を使用してください。容量変更は オペレーター認可 により保護され、監査されます。
コマンドライン状態ビューは次のとおりです。
threadcells-resource-status変更後、UI と CLI が一致することを確認してください。上限は受け入れ制御であり、スループットまたはワークロードサンドボックスの約束ではありません。
よくある間違い
- 1つのビルドが遅いからと、すべての上限を増やす。
- アイドルのワークツリーをプロバイダー実行として数える。
- 長時間のミッションを見積もるときに常駐スーパーバイザーを忘れる。
- 上限を下げるとアクティブタスクが終了されると期待する。
- GREEN 容量を、プロバイダークォータが利用可能である証拠として扱う。
- スロットを解放するために、所有ワークフローを安全に退役させる代わりにランタイムファイルを削除する。
ディスク復旧については Housekeeping、安全な子の退役については ワークフローと永続的な結果 を参照してください。