Short answer: to find what's eating your RAM on Linux, run ps aux --sort=-%mem | head — it lists every process with the biggest memory user at the top. Then run free -h and look at the "available" column, not the "free" column, to judge whether you have a problem. Usually the culprit is one obvious program — a browser with too many tabs, or an app running for days — and closing or restarting just that program fixes it. No RAM cleaner needed, and never kill processes at random. I verified this hands-on with a test process using about 300 MB: it topped the rankings, and the memory came back when I stopped it.
Step 1: Check whether RAM is actually the problem
Before hunting a culprit, check the overall picture with free -h. On my test machine (7,934 MB of RAM), the output before my test looked like this:
| Column | Reading |
|---|---|
| total | 7,934 MB |
| used | 7,337 MB |
| free | 137 MB |
| buff/cache | 827 MB |
| available | 596 MB |
If you only looked at "free", you would panic: 137 MB free on nearly 8 GB sounds like a crisis. It is not — Linux uses spare RAM as disk cache (buff/cache), given back the moment a program needs it. That is why "available" exists: the honest estimate of memory a new program can use. Here that was 596 MB: tight, but not empty.
So the rule is simple: worry about "available", not "free". If available is very low and the machine stutters, you have a real problem; if available is comfortable, the system is just using RAM the way Linux is designed to. My test machine had no swap (0 MB); on a desktop, a growing swap column plus sluggishness is another sign of real RAM pressure.
Step 2: Find the biggest process
The one command to remember:
ps aux --sort=-%mem | head
The --sort=-%mem part sorts by memory share, highest first (the minus sign means descending), and head limits output to the top ten lines. For a cleaner view with just the columns that matter, use:
ps -eo pid,comm,%mem,rss --sort=-%mem | head
What the columns mean, and which to trust:
- PID — the process ID, needed if you later stop the process.
- COMMAND / comm — the program's name; usually what identifies the culprit.
- %MEM — the process's share of total physical RAM. This is the ranking column.
- RSS — resident set size: the physical RAM the process actually holds, in kilobytes. This is the number to believe.
- VSZ — virtual memory size. Ignore it for hunting RAM hogs: it counts memory mapped but not actually used, so it is often many times larger than RSS.
Note on the ps command's sorting and columns: ps is a snapshot — perfect for "who is biggest right now". For a live view, run top and press Shift+M.
The controlled test: a 300 MB process, caught red-handed
On November 3, 2026, I ran a small Python script that allocated and touched 300 MB, then waited. The machine was a Linux virtual machine with 4 CPUs, 7,934 MB of RAM, procps-ng 4.0.4, and Python 3.12.3. While it ran, ps caught it immediately at the top of the list:
PID %MEM RSS COMMAND
13949 3.9 317468 python3
That is 317,468 KB — about 310 MB, the 300 MB allocated plus Python's overhead — or 3.9% of the machine's RAM. The artificial hog was the first row, with its real PID and size.
The free readings told the rest:
| Moment | Used | Free | Buff/cache | Available |
|---|---|---|---|---|
| Before the test process | 7,337 MB | 137 MB | 827 MB | 596 MB |
| While it was running | 7,602 MB | 167 MB | 526 MB | 331 MB |
| After I stopped it | 7,351 MB | 418 MB | 527 MB | 582 MB |
Two things stand out. First, "available" fell from 596 MB to 331 MB while the hog ran, then recovered to 582 MB after I stopped it — proof the test process was holding the memory. Second, "available" did not fall by the full 310 MB, because the system also gave back some disk cache — another reason to watch "available" rather than adding up processes. I stopped it with kill and its PID, then confirmed with a second ps run that it was gone. No reboot, no cleaner app.
Step 3: Decide what to do about the culprit
With a name and PID in hand, work through these in order, gentlest first:
1. If it is a browser, close tabs before you close the browser. Browsers run each tab (and extension) as its own process, so one browser can fill the top of your list. Closing the heaviest tabs — video and social media tabs are classic offenders — often frees hundreds of megabytes. If the browser has grown huge over days of use, restarting it is a legitimate fix.
2. If it is an app you recognise, close or restart it normally. A video editor, a game, or an IDE holding a big project legitimately uses a lot of RAM while it works — that is not a bug. If it stays huge after you close the project, restarting the app clears it.
3. Check for a leak before you blame the app. A leak is when usage keeps growing without the program doing more work. Test it by running the same command twice, an hour apart, on a process you have not used in between:
ps -o pid,%mem,rss,comm -p <PID>
If RSS climbs steadily while the program sits idle, that is leak behaviour. Fix it by updating the program or restarting it periodically — and report the leak with the two RSS readings as evidence.
4. Only then, stop the process from the terminal. A plain kill <PID> asks it to shut down cleanly — try that first. Only if it refuses should you escalate to kill -9 <PID>, which forces it to stop with no chance to save anything. Never run either on a process you do not recognise.
What not to kill, and other traps
- Do not kill PID 1, system services, or anything you cannot name. Stopping the wrong system process can crash your session. If
systemdor your desktop shell uses a normal amount of memory, leave it alone. - Do not add up every RSS value and expect it to equal "used". Processes share libraries, counted in each process's RSS, so adding the column up overcounts, especially with browsers. Judge processes individually, and the system by "available".
- Do not install a "RAM booster" or "memory cleaner". On Linux these mostly flush the disk cache that was making your machine faster. Closing the culprit beats clearing cache every time.
FAQ
How do I find which process is using the most RAM on Linux?
Run ps aux --sort=-%mem | head. The top rows are the biggest RAM users, ranked by %MEM. Use ps -eo pid,comm,%mem,rss --sort=-%mem for a shorter version.
Why does free show almost no free RAM when my computer feels fine?
Because Linux fills unused RAM with disk cache. Check "available" in free -h instead — the memory usable by new programs. Low "free" with comfortable "available" is normal.
How do I free RAM on Linux without rebooting?
Close or restart the specific program using the memory — find it with ps aux --sort=-%mem, then close it normally or use kill <PID>. A reboot works too, but a targeted restart is the sharper option.
Verdict
Finding a RAM hog takes two commands and about a minute: free -h to see whether you have a problem (read "available"), and ps aux --sort=-%mem to name the culprit (read RSS, ignore VSZ). My test proved both ends — a 300 MB process topped the ranking at 317,468 KB, and available memory fell while it ran and recovered when I stopped it. Start with browser tabs, restart before you kill, and leave system processes alone. If no process stands out and "available" is still low, you may simply need more RAM, not a cleaner app.
How this article was made
I tested this on November 3, 2026, on a Linux virtual machine (4 CPUs, 7,934 MB RAM, procps-ng 4.0.4, Python 3.12.3): baseline free -m, ps, and top readings, then a Python script allocating 300 MB, its PID, %MEM, and RSS (317,468 KB) plus free readings while it ran, then a kill and a re-check showing available memory recovered. Background on ps sorting and columns was checked against the Linuxize ps guide. No RAM-cleaner or GUI tool was tested, so none is recommended. This article was drafted with AI assistance and checked against the test results above.
