Whoever starts a run's process measures it: the scheduler for a local or
control-placed run (orca.scheduler), orca worker for a remote worker's
(orca.worker). Each tick, at most every quarter of a second, it reads
the process's tree in /proc (orca.sample.tree_usage: the driver and what
it started, dista's local workers among them) and keeps a Meter of it:
the resident bytes, the CPU seconds so far (utime + stime, with what the
tree's processes waited for), and the cores that kept busy since the
sample before. When the process is reaped, wait4 adds its own word:
ru_maxrss, the largest single process (a lower bound on the tree's), and
its CPU seconds, which count descendants that ended after the last sample.
A process runs every attempt of a run's start, so its samples are shared
out among those attempts by time (attribute): an attempt's peak is the
largest sample taken while it ran (or, for one shorter than a tick, the
sample just after it), its CPU the meter's CPU at its end less at its
start, its peak cores the busiest interval it overlapped. ru_maxrss
raises the peak of a process's only attempt. A meter keeps at most
MAX_MARKS samples, merging neighbours as it fills (keeping their maximum
and the later total), so a long run's samples are coarser, not dropped.
On macOS, which has no /proc, there are no samples: a process's only
attempt gets wait4's numbers, and none gets its peak cores; a process
of several attempts records none. Runs on EC2 or Kubernetes, and runs no
scheduler or worker started (<binary> run by hand), record nothing:
their columns stay NULL.
The numbers are orca.attempts' peak_rss_bytes, cpu_seconds and
peak_cpus (migration 35), written once, when the process ends: by the
scheduler over Postgres, and for a worker's run by orca ui, which the
worker sends its meter with /api/worker/exited (marks_json, ages in
seconds before the request, so neither clock needs to agree with the
database's).