How to Monitor System Activity with ProcessController on Haiku

ProcessController is Haiku’s compact CPU/memory monitor and team/thread control applet. It can live in Deskbar, a small window, or as a Replicant on the Desktop. Its context menus reach deep enough to change thread priority, kill threads or teams, disable processors, and enter power-saving mode, so observation and intervention should be treated as separate phases.

Launch it in the form you can verify

Open Deskbar → Desktop Applets → ProcessController. If it is not already running, the official guide says it asks whether to open in window mode or live in Deskbar. It is not safe to assume every installation already has the tray item enabled.

Window mode can be resized, and its Replicant handle can place it on the Desktop. To remove the Deskbar instance, uncheck Live in the Deskbar from its context menu. ProcessController has no persistent settings listed by the user guide, so document placement manually if it matters to a test.

Wherever it lives, operate ProcessController with a right-click context menu. The previous article described a separate “Show Teams” window and double-click thread view; that is not the interaction documented for the current applet.

Read the compact indicators accurately

The indicators on the left show activity for each processor/core; the bar on the right represents used memory. The number of CPU indicators therefore depends on hardware and enabled cores. A short spike during application launch, indexing, package activation, or rendering can be normal.

Do not diagnose from one glance. Observe an idle baseline, reproduce the slowdown, note duration and whether one/all cores rise, then let the system return to baseline. Persistent saturation is stronger evidence than a transient full bar.

CPU percentage alone does not explain whether work is useful. Pair it with the application action, responsiveness, I/O, and repeated thread samples. A team can be hung while consuming almost no CPU because its window thread is waiting forever.

Open Threads and CPU usage. At the first level ProcessController lists teams; the next level exposes their threads, and the final level offers thread-priority controls. The official color explanation distinguishes time in kernel code, user code, and idle threads.

A fully busy team bar shows that team consuming available processing time. A fully busy thread bar indicates that thread is pegging one processor/core. Record team name, thread name/ID if shown, kernel-versus-user proportion, start/end time, triggering action, and Haiku/application revision.

Repeat observations. For a CPU regression, capture the same workload on a known-good build with comparable hardware and settings. If one thread remains hot, attach Debugger and save several stacks; repeated identical locations are more informative than the applet color alone.

Do not click a team or thread while merely trying to expand a menu without reading the documented action. At certain levels, clicking can kill or debug rather than only select.

Interpret memory as an estimate

The Memory usage menu shows teams with two values. The first is writable memory reserved for that application; the second includes read-only address space such as shared libraries. Shared pages can appear in several teams’ totals, so adding every row does not produce a reliable physical-memory total.

The official guide explicitly warns that monitoring memory can be inaccurate. The system-resources/caches row is scaled against total physical memory, while individual process bars are scaled against the currently used portion. Equal-looking bar lengths across different moments are not necessarily equal byte counts.

For a suspected leak, reproduce the same operation repeatedly, record the numeric writable and total values at fixed intervals, allow caches/workers to settle, and compare after closing documents or returning to idle. A monotonic increase across controlled cycles is evidence worth investigating; one allocation jump followed by a plateau is not automatically a leak.

Correlate with ActivityMonitor and application-specific diagnostics. Check whether memory returns after quit and whether a surviving helper team owns it. Preserve exact units and avoid converting a virtual/read-only total into a claim about exclusive RAM.

Ask an application to quit before killing it

The Quit an application menu sends a normal quit request, comparable to closing the application. Use it first after saving work. Give the app time to present unsaved-document dialogs or finish an operation.

If it remains frozen, capture evidence before stronger action: screenshot/context, ProcessController team/thread state, Debugger report or stacks, input steps, document copy, and system revision. Then use a kill only when loss of unsaved work and incomplete writes are acceptable.

Never experiment by quitting or killing system servers and daemons. The user guide warns this can make the system unreliable. Killing a thread inside a team is particularly risky because other threads may continue with locks held, invariants broken, or partially modified files.

When the desktop offers Team Monitor for an unresponsive application, its normal quit/kill path may be clearer for recovery. ProcessController’s value is continuous observation plus drill-down, not bypassing every safer shutdown route.

Leave priorities alone during diagnosis

ProcessController can change a thread’s priority. That does not repair a busy loop, deadlock, excessive wakeups, or bad I/O design. Raising a faulty thread can starve UI or system work; lowering a latency-critical media/system thread can create new symptoms.

Record the original priority before any controlled experiment and restore it afterward. Change one non-system test thread only when a developer’s hypothesis requires it. The official guide’s advice is conservative: application authors should fix priority policy in code rather than asking users to tune it interactively.

Likewise, disabling a processor/core changes scheduler behavior and performance and may mask a race. Power-saving mode intentionally trades slightly increased latency for power use. Neither belongs in a routine “make the system faster” checklist. Use them only for a documented comparison with a recovery plan.

Build a repeatable monitoring capture

Before reproduction, record revision, architecture, core count, physical memory, power mode, running background work, temperature/power state if relevant, and the baseline ProcessController display. Define one workload with fixed input and duration.

During the workload, note:

Which CPU indicators change and for how long.
The team and thread that remain high across samples.
Kernel versus user time pattern.
Writable and total memory at fixed checkpoints.
UI response, I/O, and whether the condition clears.
Any intervention and its exact time.

Afterward, save Debugger stacks for hot/hung threads, application logs, and a comparison run. Redact private document names or memory content before a public ticket, but keep technical values intact.

Combine tools instead of overclaiming

Use ProcessController for persistent at-a-glance state and quick team/thread identification. Use ActivityMonitor for plotted system metrics over time, Terminal tools such as ps/top for scriptable snapshots, Team Monitor for a frozen desktop application, and Debugger for stacks, symbols, variables, and deadlock evidence.

Each answers a different question. ProcessController can show that a thread consumes one core; it cannot by itself prove which source loop is wrong. It can show rising address-space figures; it cannot alone distinguish a leak from shared libraries, caches, or intentional retained data.

The safe workflow is observe, reproduce, identify, capture, then intervene. If killing or reprioritizing is the first step, the state needed to explain the problem is usually gone.

Related:

Sources: