Check memory usage in Linux: find the top memory and CPU users

You’ll create two small Python programs that use memory in different ways, plus one CPU burner, and read them with every tool from this lesson. All of it runs as student in ~/lab22 on rocky01, and you’ll stop everything at the end. Start with mkdir -p ~/lab22 && cd ~/lab22.

1Read free -h the right way

Run this:

free -h

You should see something like this:

               total        used        free      shared  buff/cache   available
Mem:           1.7Gi       456Mi       1.0Gi       8.8Mi       415Mi       1.3Gi
Swap:          2.0Gi          0B       2.0Gi

rocky01 has 2 GB in VirtualBox, and the kernel shows 1.7Gi total after keeping some for itself. Look at available first: 1.3Gi can go to new programs without swapping. Swap shows 2.0Gi total and nothing used, which is what you want to see.

The -h means “human” units in powers of 1024 (Gi, Mi); add -m for plain MiB numbers in scripts.

✅ Checkpoint: You can say how much memory is available on rocky01 and whether any swap is used.

2Look behind free in /proc/meminfo

Run this:

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapCached|SwapTotal|SwapFree|AnonPages|Shmem|SReclaimable):' /proc/meminfo

You should see something like this:

MemTotal:        1784013 kB
MemFree:         1034060 kB
MemAvailable:    1316722 kB
Buffers:            4908 kB
Cached:           371820 kB
SwapCached:            0 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB
AnonPages:        318400 kB
Shmem:              9032 kB
SReclaimable:      48356 kB

All values are in kB (kibibytes). Check the arithmetic yourself: buff/cache is Buffers + Cached + SReclaimable = 4908 + 371820 + 48356 = 425084 kB, which free shows as 415Mi. used is MemTotal minus MemAvailable = 467291 kB, about 456Mi. AnonPages is memory programs have written to, the part that can only go to swap, never be dropped.

✅ Checkpoint: Your buff/cache and used numbers match the sums from your own meminfo.

3Start a memory hog and a lazy reserver

Create both programs (paste this whole block):

cat > ~/lab22/hog.py <<'EOF'
#!/usr/bin/env python3
# hog.py: fills N MiB of RAM and holds it until you stop it
import os, sys, time
mib = int(sys.argv[1]) if len(sys.argv) > 1 else 200
data = b"x" * (mib * 1024 * 1024)
print(f"hog: PID {os.getpid()} is holding {mib} MiB", flush=True)
time.sleep(3600)
EOF
cat > ~/lab22/lazy.py <<'EOF'
#!/usr/bin/env python3
# lazy.py: reserves 1 GiB of address space but never touches it
import mmap, os, time
area = mmap.mmap(-1, 1024 * 1024 * 1024)
print(f"lazy: PID {os.getpid()} reserved 1 GiB", flush=True)
time.sleep(3600)
EOF
python3 -m py_compile ~/lab22/hog.py ~/lab22/lazy.py && echo syntax ok

Start them in the background:

cd ~/lab22
python3 hog.py 290 &
python3 lazy.py &
sleep 2; free -h

You should see something like this:

[1] 2480
[2] 2481
hog: PID 2480 is holding 290 MiB
lazy: PID 2481 reserved 1 GiB
               total        used        free      shared  buff/cache   available
Mem:           1.7Gi       751Mi       714Mi       8.8Mi       415Mi       991Mi
Swap:          2.0Gi          0B       2.0Gi

available dropped by about 300 MiB, from 1.3Gi to 991Mi, and used went up by the same amount. lazy.py reserved a whole gigabyte, yet free barely noticed it, because it never wrote to that memory.

✅ Checkpoint: Both programs printed their PID and available dropped by roughly 290 MiB.

4Rank processes by memory, ten of them

Run this:

ps aux --sort=-%mem | head -n 11

You should see something like this:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
student     2480  0.3 16.9 332548 301824 pts/0   S    11:05   0:00 python3 hog.py 290
root         812  0.1  2.6 412396 46080 ?        Ssl  09:01   0:01 /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid
root           1  0.0  2.3  49288 40192 ?        Ss   09:01   0:02 /usr/lib/systemd/systemd --switched-root --system --deserialize=46 rhgb
root        1046  0.0  1.8 421768 32768 ?        Ssl  09:01   0:00 /usr/bin/python3 -sP /usr/sbin/tuned -l -P
root         868  0.0  1.2 331008 21504 ?        Ssl  09:01   0:00 /usr/sbin/NetworkManager --no-daemon
polkitd      790  0.0  1.1 385412 19968 ?        Ssl  09:01   0:00 /usr/lib/polkit-1/polkitd --no-debug --log-level=notice
root         612  0.0  1.0  48864 17408 ?        Ss   09:01   0:00 /usr/lib/systemd/systemd-journald
student     1838  0.0  0.8  22688 14592 ?        Ss   10:15   0:00 /usr/lib/systemd/systemd --user
root         655  0.0  0.7  35720 13312 ?        Ss   09:01   0:00 /usr/lib/systemd/systemd-udevd
root         805  0.0  0.6  19980 11520 ?        Ss   09:01   0:00 /usr/lib/systemd/systemd-logind

hog.py is at the top with an RSS of 301824 kB (about 295 MiB) and 16.9 %MEM. The head -n 11 gives you the header plus ten processes. For a ticket or a script, choose your own columns and let ps sort by RSS directly:

ps -eo pid,user,%mem,rss,vsz,cmd --sort=-rss | head -n 6

You should see something like this:

    PID USER     %MEM   RSS    VSZ CMD
   2480 student  16.9 301824 332548 python3 hog.py 290
    812 root      2.6 46080 412396 /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid
      1 root      2.3 40192  49288 /usr/lib/systemd/systemd --switched-root --system --deserialize=46 rhgb
   1046 root      1.8 32768 421768 /usr/bin/python3 -sP /usr/sbin/tuned -l -P
    868 root      1.2 21504 331008 /usr/sbin/NetworkManager --no-daemon

-eo lists every process with the columns you name, and --sort=-rss sorts on the real number (in kB) instead of the rounded percentage. Add --no-headers when another tool will read the output.

Try it yourself: build the top-memory command, with or without the header, in the Command Builder.

✅ Checkpoint: hog.py is the first process in both lists.

5See why VSZ lies and RSS tells the truth

Sort by VSZ instead:

ps -eo pid,user,%mem,rss,vsz,cmd --sort=-vsz | head -n 4

You should see something like this:

    PID USER     %MEM   RSS    VSZ CMD
   2481 student   0.6 11100 1084160 python3 lazy.py
   1046 root      1.8 32768 421768 /usr/bin/python3 -sP /usr/sbin/tuned -l -P
    812 root      2.6 46080 412396 /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid

lazy.py now looks like the biggest process on the box with over 1 GB of VSZ, but its RSS is 11100 kB, about 11 MiB. Java, databases and browsers often show huge VSZ for the same reason. Look inside hog.py with its status file and pmap (use your own PID):

grep -E '^(VmSize|VmRSS|RssAnon|RssFile|VmSwap)' /proc/2480/status
pmap -x 2480 | tail -n 1

You should see something like this:

VmSize:	  332548 kB
VmRSS:	  301824 kB
RssAnon:	  294400 kB
RssFile:	    7424 kB
VmSwap:	       0 kB
---------------- ------- ------- -------
total kB          332552  301824  294660

VmSize is VSZ, VmRSS is RSS, and RSS splits into RssAnon (its own data, the 290 MiB) and RssFile (the Python program and libraries mapped from disk). VmSwap shows how much of it has been pushed to swap. The pmap total line gives the same sizes; drop the | tail to see every mapping.

✅ Checkpoint: You can explain why lazy.py has a big VSZ and a tiny RSS.

6Take a top snapshot for the ticket

Run this:

top -b -n 1 -o %MEM | head -n 12

You should see something like this:

top - 11:08:41 up  2:07,  1 user,  load average: 0.02, 0.05, 0.01
Tasks: 137 total,   1 running, 136 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  3.0 sy,  0.0 ni, 97.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   1742.2 total,    714.8 free,    751.2 used,    415.1 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.    991.0 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2480 student   20   0  332548 301824   7424 S   0.0  16.9   0:00.21 python3
    812 root      20   0  412396  46080  13952 S   0.0   2.6   0:01.12 firewalld
      1 root      20   0   49288  40192  10624 S   0.0   2.3   0:02.11 systemd
   1046 root      20   0  421768  32768  12288 S   0.0   1.8   0:00.64 tuned
    868 root      20   0  331008  21504  17920 S   0.0   1.2   0:00.41 NetworkManager

-b is batch mode (plain text, no screen control), -n 1 takes one snapshot and -o %MEM sorts by memory. The field name must be written the way top prints it, %MEM or %CPU. Here the header is seven lines, so head -n 12 gives five processes.

The “MiB Mem” and “MiB Swap” lines tell the same story as free, with avail Mem on the swap line.

top -b -n 1 -o %MEM > ~/lab22/top-$(hostname -s)-$(date +%F-%H%M).txt
ls ~/lab22/top-*

✅ Checkpoint: A file named like top-rocky01-2026-10-27-1108.txt exists in ~/lab22.

7Find the CPU hog

Start a CPU burner and wait about 30 seconds:

sha256sum /dev/zero &
sleep 30
ps -eo pid,user,%cpu,time,etime,cmd --sort=-%cpu | head -n 4

You should see something like this:

    PID USER     %CPU     TIME     ELAPSED CMD
   2502 student  98.7 00:00:29       00:30 sha256sum /dev/zero
   2480 student   0.0 00:00:00       03:12 python3 hog.py 290
    812 root      0.1 00:00:01    02:07:40 /usr/bin/python3 -sP /usr/sbin/firewalld --nofork --nopid

sha256sum reads zeros forever and keeps one CPU at almost 100 percent. In ps, %CPU is CPU time divided by run time, so TIME 29 seconds over ELAPSED 30 seconds is 98.7 percent. A process that was idle for a day and then spiked would still show a low %CPU here, so check top too, with two snapshots one second apart:

top -b -n 2 -d 1 -o %CPU | grep -A 2 '^ *PID' | tail -n 3

You should see something like this:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2502 student   20   0    7932   3268   2724 R  99.7   0.2   0:33.18 sha256sum
   2001 student   20   0  231460   5632   3456 R   0.3   0.3   0:00.04 top

The second snapshot measures the last second only, which is what “busy right now” means. Stop the burner with kill %3 (or its PID).

Try it yourself: build the top-CPU command in the Command Builder.

✅ Checkpoint: sha256sum topped both lists, and after kill it no longer appears in ps.

8Watch page cache grow and come back

Write a 400 MiB file, then look at free:

dd if=/dev/zero of=~/lab22/big.bin bs=1M count=400
free -h

You should see something like this:

400+0 records in
400+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 0.912214 s, 460 MB/s
               total        used        free      shared  buff/cache   available
Mem:           1.7Gi       757Mi       314Mi       8.8Mi       815Mi       985Mi
Swap:          2.0Gi          0B       2.0Gi

Compared with step 3, buff/cache grew by 400 MiB and free dropped by the same amount, but available moved only from 991Mi to 985Mi, because the kernel can drop that cache the moment hog.py or anything else needs it. Delete the file and stop the test programs:

rm ~/lab22/big.bin
kill %1 %2
free -h

✅ Checkpoint: After cleanup, available on rocky01 is back near the 1.3Gi you saw in step 1.