AITM は、いま実際に何が実行中で、何が待機中で、何がリソースを消費しているかを随時確認できる、ライブのリソース監視ビューを提供します。タスクが待機したまま止まっている理由の診断や、クラッシュ前のリソース逼迫の発見に役立ちます。
Resource Monitor
モニターが扱う上限値は Settings → Watchdog & Resources(Disk Janitor の保持期間、Disk Watchdog の GB 予算、テスト用の CPU/RAM 予約)で設定します。同時に実行されるタスクの数は Settings → Pipeline → Max concurrently running tasks にあります。以下で説明するプールのスロットは内部のリソーススロットであり、ライセンスのプロジェクトスロットではありません。
「Queued」タブ
モニターバーには「Queued」タブがあり、実行に取り上げられる前の、実行待ちのタスクが一覧表示されます。
実行スナップショットとステータスバーの「Pools」セグメント
ステータスバーの「Pools」セグメントには、ライブの実行スナップショットが表示されます。実行中または待機中の各タスクについて、waitKind(どの種類のリソースを待っているか)と waitedMs(どれだけ待機しているか)、現在どのプール保持者がスロットを保持しているか、そしてアドミッション/逼迫のインジケーターが示されます。これにより、タスクが滞留し始める前に、プールが競合状態にあることを確認できます。
Threads パネル — 実測 RSS に基づくプールのサイジング
汎用化された Threads パネルには、リソースプールごとに、個々の保持者がその PID と実測 RSS(常駐メモリ)とともに表示されます。そのため、プールの容量は静的な推測ではなく、実際に測定されたメモリ使用量に基づいて決定されます。
tmpfs メトリクス
Resource Monitor の UI には tmpfs(メモリ上のファイルシステム)の使用量メトリクスも表示されるため、プロセス/プールの逼迫と並べて、メモリを裏付けとするディスクの逼迫も確認できます。
グローバルなテストランナースロットプール
Threads パネルには、グローバルなテストランナーのスロットプール、つまりプロジェクト全体で使用中のテスト実行スロットの数も表示されます。これにより、タスクのテストステップが、すべてのテストランナースロットが埋まっているために待機しているのかどうかが分かります。
ヒント
- タスクが止まっていると判断する前に、Pools セグメントの waitKind を確認してください。単にビジー状態のプールを待っているだけかもしれません。
- Threads パネルの保持者ごとの RSS を使うと、暴走したプロセスが OOM になる前に見つけられます。
- Queued タブが増え続ける場合は、プールの逼迫インジケーターを確認して、ボトルネックを特定してください。