Reading a Job

Pick a job in Jobs and click View charts. A multi-node job appears as one row, not one per node — the per-node files are folded together for you.

For a large job, Download for charts fills the local chart cache first and shows progress for each node log. You can also open live charts directly. Downloads are queued, with up to two node logs transferring at once. Cancel download keeps completed progress so you can continue later. The Jobs list shows local cache usage and lets you remove a job's cached data or clear history older than seven days; neither action deletes files on the cluster.

The tabs

The job opens on Nodes. The earlier System tab is no longer present; process and thread counts remain available in the Compare chart selector.

Time windows and exports

Each time graph has its own Time window menu: full range, a recent preset, or a custom start and end. Zoom in and Zoom out adjust that graph's window. The Cores bars recalculate their averages for the selected window. Live chart cards and exports use all retained samples, independent of the graph window.

Export JSON and Export CSV save chart data through a file picker. A long-running job may exceed the app's in-memory sample limit. In that case the export contains only the trailing window and its filename includes trailing-window; the JSON also records that the series is partial. The merged Summary remains the source for whole-run totals.

Start with Cores

This is the one question a job-level average cannot answer.

37% efficiency might be 18 of 48 cores pinned flat with the rest idle, or all 48 running at 37%. Identical averages, opposite fixes — the first says request fewer cores, the second says your code is not scaling and fewer cores would not help.

The bar chart sorts busiest first, so the shape tells you which you have. A cliff means cores were booked and not used. A flat line near the average means the work was spread but never saturated anything. Check the selected time window before using that shape to plan the next run.

Per-core data comes from cgroup v1 accounting. On a system using the cgroup v2 unified hierarchy this view is unavailable — v2 exposes only a total — and the tab says so rather than showing an empty chart.

Reading the CPU numbers

CPU efficiency is total CPU used over total cores booked. It is a ratio of two sums, not an average of percentages, so nodes with different core counts weight correctly.

Peak cores busy is clamped to the number you booked. A job cannot use more cores than it has; readings above that are a sampling artefact, because cgroup CPU counters advance in coarser steps than the window they are measured over, so one window can pick up time belonging to the previous one. The panel says when it has clamped, and the average is unaffected.

Memory

Prefer the cgroup figure the app shows by default. The older summed-RSS number double-counts pages shared between processes, which for MPI ranks on one node is badly wrong — it can report several times the memory actually in use.

Memory is shown as a percentage of your booking when the booking is known, and in GB when it is not.

Multi-node jobs

Nodes reporting tells you how many of the allocation are currently sending samples. Early in a job that just means a logger has not started yet; later it means one has stopped, and the totals understate the job.

Last Sample is the liveness signal for a single-node job, where the node count alone cannot show that the logger stopped. A warning appears after 30 seconds without a new sample while the job is believed to be running. A connection interruption can also freeze charts; the app shows reconnection attempts and resumes when it can read the files again.

Rates and gaps

Disk and network figures are per-second rates, derived from each node's own measured sampling interval — the logger records 0.511s where 0.5s was requested — and only then summed.

Where an interval is unknown, the chart draws a gap rather than a zero. A zero would read as a moment of no I/O that never happened. The same applies to a node that missed a sample, and to a GPU that did not report.

What is node-scoped, not job-scoped

Two figures describe the whole machine, not just your job:

• Network is always node-wide. /proc/net/dev has no notion of job ownership. Treat it as an upper bound: exact on an exclusive node, inflated on a shared queue.
• GPU is job-scoped when the scheduler set CUDA_VISIBLE_DEVICES, which it does for GPU jobs. Without it, readings stay node-wide and are labelled as such.

The app never has to guess — every sample carries a flag saying which it is.

Jobs with no Summary

Summary, Advice and Compare all read the merged whole-run summary, written once every node has stopped. A running job does not have one yet; the view picks it up on its own when the job ends. See Troubleshooting if it never appears.