Memory by Program

Memory by Program

loadbearer mem is a diagnostic, not a benchmark — nothing it prints is scored or graded. It answers "what is using this machine's RAM right now?", grouped by program, in the style of ps_mem: smallest first, so the heaviest consumers sit right above the grand total.

loadbearer mem
loadbearer mem --limit 15          # just the 15 biggest (total still covers all)
loadbearer mem --swap              # add a Swap column (Linux)
loadbearer mem --json              # structured output

What the numbers are

Linux — true PSS

On Linux the figures are PSS (proportional set size), read from /proc/<pid>/smaps_rollup:

Column	Meaning
Private	Pages mapped only by this process — Private_Clean + Private_Dirty. Its heap, its stacks, its relocated/dirtied library pages.
Shared	Its proportional share of pages mapped by more than one process. A libc page mapped by 60 processes counts 1/60 toward each. Computed as Pss − Private.
RAM used	Private + Shared = Pss.
Swap (--swap)	Proportional paged-out size — SwapPss, falling back to Swap on older kernels.

Because shared pages are counted once across their sharers, the per-program RAM used values sum to something close to the RAM actually in use — which is the whole reason to use PSS over RSS (RSS counts every shared page in full against every process that maps it, so RSS totals are wildly inflated).

Reading another user's process needs root. An unprivileged loadbearer mem sees only your own processes; the footer reports how many it had to skip, and the total is short by their memory. Run it with sudo for the whole machine.

Windows — working set

Windows has no PSS. There:

Column	Meaning
RAM used	The process working set (WorkingSetSize).
Private	PrivateUsage (private commit), capped at the working set.
Shared	The remainder, RAM used − Private — an estimate, not a true proportional accounting.

--swap shows nothing useful on Windows and the column is omitted. The report footer states which kind of number you're looking at, so a Linux PSS snapshot and a Windows working-set snapshot are never silently conflated.

Grouping

Processes are grouped by program name — the basename of the executable (cmdline[0]; the pre-whitespace part, so title-rewriting programs like Firefox and Chrome still collapse into one row). A row with more than one process is tagged with the count, e.g. firefox (17). Kernel threads show as [kthreadd] and contribute ~nothing.

Rows are sorted ascending by total, so on a terminal that has scrolled, the biggest consumers are the ones still on screen next to the total.

--json

{
  "schema": "loadbearer.mem/1",
  "tool_version": "1.0.0",
  "source": "pss",
  "programs": [
    { "name": "firefox", "processes": 17,
      "private_bytes": 1764564992, "shared_bytes": 76601344, "swap_bytes": 504893440 },
    ...
  ],
  "unreadable": 50
}

source is "pss" on Linux, "working-set" on Windows. programs is ordered smallest-total first. unreadable is the number of processes that exist but couldn't be read without more privilege — add it mentally to any total you compute from this.

Why it's here

loadbearer is a machine-assessment tool; mem is the same kind of "know your machine" utility as info. It's useful right after a run that graded low on memory, or on a fleet machine that's swapping — loadbearer mem --json over SSH is a quick, dependency-free ps_mem.