AITM bietet eine Live-Ansicht zur Ressourcenüberwachung, in der sich jederzeit erkennen lässt, was tatsächlich läuft, wartet und Ressourcen verbraucht — nützlich, um zu diagnostizieren, warum ein Task wartend festhängt, oder um Ressourcendruck vor einem Absturz zu erkennen.
Resource Monitor
Die Grenzwerte, mit denen der Monitor arbeitet, werden unter Settings → Watchdog & Resources festgelegt (Aufbewahrung des Disk Janitor, GB-Budgets des Disk Watchdog, CPU-/RAM-Reservierungen für Tests); die Anzahl gleichzeitig laufender Tasks steht unter Settings → Pipeline → Max concurrently running tasks. Die unten beschriebenen Pool-Slots sind interne Ressourcen-Slots, keine Lizenz-Projekt-Slots.
Der Tab "Queued"
Die Monitor-Leiste hat einen Tab "Queued", der Tasks auflistet, die auf ihre Ausführung warten, bevor sie zur Bearbeitung aufgenommen werden.
Execution-Snapshot & das Segment "Pools" der Statusleiste
Das Segment "Pools" der Statusleiste zeigt einen Live-Snapshot der Ausführung: Für jeden laufenden oder wartenden Task werden waitKind (auf welche Art von Ressource er wartet) und waitedMs (wie lange er schon wartet) angezeigt, dazu, welche Pool-Halter aktuell einen Slot belegen, sowie Indikatoren für Zulassung und Druck, sodass erkennbar ist, wann ein Pool unter Konkurrenz steht, bevor sich Tasks zu stauen beginnen.
Threads-Panel — Pool-Dimensionierung nach gemessenem RSS
Das verallgemeinerte Threads-Panel zeigt pro Ressourcen-Pool die einzelnen Halter mit PID und gemessenem RSS (Resident Memory), sodass die Pool-Kapazität anhand tatsächlich gemessener Speichernutzung statt einer statischen Schätzung dimensioniert wird.
tmpfs-Metriken
Die Oberfläche des Resource Monitor zeigt außerdem Nutzungsmetriken von tmpfs (Dateisystem im Arbeitsspeicher), sodass sich der speichergestützte Plattendruck neben dem Prozess-/Pool-Druck beobachten lässt.
Globaler Pool der Test-Runner-Slots
Das Threads-Panel zeigt auch den globalen Pool der Test-Runner-Slots, d. h. wie viele Testausführungs-Slots projektübergreifend belegt sind, sodass erkennbar ist, ob der Test-Schritt eines Tasks wartet, weil alle Test-Runner-Slots belegt sind.
Gut zu wissen
- Vor der Annahme, ein Task hänge fest, lohnt ein Blick auf waitKind im Segment Pools — er wartet womöglich nur auf einen ausgelasteten Pool.
- Mit dem RSS pro Halter im Threads-Panel lässt sich ein außer Kontrolle geratener Prozess erkennen, bevor er einen OOM verursacht.
- Wächst der Tab Queued weiter an, zeigen die Druckindikatoren der Pools den Engpass.