ps aux --sort: Rank Processes by Memory and CPU
ps aux --sort=-%mem lists processes by memory use, heaviest first, so you can name what is exhausting a runner before the OOM killer does.
After an exit 137 or a slow build, you want the one process eating the box. ps aux with a sort key gives a ranked snapshot without an interactive tool.
What it does
ps aux prints every process with %CPU, %MEM, VSZ (virtual size), and RSS (resident set size, the real physical memory). --sort=-%mem orders by memory descending; --sort=-%cpu by CPU. RSS is the number that matters for OOM; VSZ is mostly reserved address space.
Common usage
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
# RSS in MB for the top consumers
ps -eo pid,comm,rss --sort=-rss | head | awk 'NR>1{$3=$3/1024"MB"}1'Options
| Field / flag | What it does |
|---|---|
| aux | All processes, user-oriented columns |
| --sort=-%mem | Sort by memory, descending |
| --sort=-%cpu | Sort by CPU, descending |
| RSS | Resident memory in KB (real RAM used) |
| VSZ | Virtual memory size in KB (reserved, not all resident) |
| -o <fields> | Pick exact columns to print |
In CI
High VSZ with low RSS is normal (e.g. the JVM reserving address space) and is not what triggers OOM; sort by RSS or %MEM to find the real consumer. Snapshotting ps aux --sort=-%mem | head periodically (see the watch reference) during a build captures the peak just before a kill.
Common errors in CI
Reading VSZ as "memory used" is the common mistake: a process can show 20G VSZ and use 200M RSS. The OOM killer scores on RSS-like memory, so trust RSS. If %CPU exceeds 100, that is multi-core: a value of 380 means roughly 3.8 cores busy, not an error.