What is the difference between top and htop?

They read the same numbers out of /proc, so neither is more accurate than the other. top is part of procps-ng and is already on the server; it takes keystrokes, and with -b it prints plain text you can pipe into a script. htop is a separate install with a colour meter for every core, mouse support, incremental search and filter, a tree view, and a kill menu that works on several tagged processes at once. It has no batch mode, so nothing about htop is scriptable. Use htop when you are looking at the box yourself, top when a cron job or a monitoring check is doing the looking.

What do the colours in htop mean?

Each meter across the top is stacked, so every colour is a different kind of use, not a different process. In the CPU bars green is normal user processes, red is kernel time, blue is low priority work that has been reniced, and cyan is virtualisation (steal and guest time). In the memory bar green is memory processes are actually using, blue is buffers, magenta is shared memory and yellow is disk cache. Yellow is not a problem: the kernel hands cache back the moment something needs it. In the process list below, a green name is a userland thread and a red one is a kernel thread. Start htop with -C to drop colour entirely.

What does load average mean in top?

The three numbers on the first line are the average number of processes running or waiting to run over the last 1, 5 and 15 minutes. They are counts, not percentages, so compare them to your core count from nproc: 4.00 on four cores means fully used with nothing queued, and 12.00 on four cores means three deep in the queue. Read them left to right for direction, since 8.0, 4.0, 1.0 is a problem building and 1.0, 4.0, 8.0 is one already passing. Linux also counts processes stuck in uninterruptible sleep, so a dead NFS mount or a failing disk can push load into double figures while the CPU sits 95% idle. Check the wa figure when that happens.

What is the difference between VIRT, RES and SHR in top?

VIRT is everything the process has mapped, including memory it reserved and never touched and files it mapped but never read. A JVM or a Go binary routinely shows tens of gigabytes of VIRT on a machine with 8 GB of RAM, which is normal and means nothing. RES is the physical RAM the process is really holding, and it is the number to read. SHR is the part of RES shared with other processes, mostly libraries, so adding up RES across a process list counts the same shared pages several times and comes out higher than your total memory. For what is genuinely free, use the avail Mem figure at the end of the swap line rather than free.

How do I sort htop by memory?

Press Shift+M for memory, Shift+P for CPU, Shift+T for time, or F6 to pick any column from a list. With the mouse on, clicking a column header sorts by it, and pressing I inverts the order. To start that way, run htop -s PERCENT_MEM (column names are the ones in F2 > Columns). htop writes its settings to ~/.config/htop/htoprc when you quit, so the sort you left it on is the one you get next time; delete that file to go back to defaults. In top the same keys work, or start it with top -o %MEM, and press Shift+W to save the layout to ~/.toprc.

htop Commands & top Cheat Sheet: Sort, Keys, Output (2026)

top Basics

is installed everywhere and needs no arguments. Press to leave it.

Command	What it does
	Live process list, sorted by CPU
	Only one user's processes
	Only this PID (comma-separate up to 20)
	Show the full command line instead of the program name
	Show individual threads rather than whole processes
	Hide idle processes
	Refresh every 5 seconds
	Quit after three refreshes
	One plain-text sample, for scripts and pipes
	Start sorted by memory
	Show the summary memory in GiB (, , , )
	Print the procps-ng version and exit

Keys while it is running:

Key	Action
	Help screen ( leaves it)
	Quit
	Refresh now
	Kill: type the PID, then the signal (15 first, 9 if that fails)
	Renice: type the PID, then the new nice value
	Toggle the full command line
	Forest view: children indented under their parent
	Field editor: add, remove and reorder columns
	Highlight the column you are sorting by
	Toggle colour
	Save the current layout to

Reading top Output

Five header lines describe the machine, then the table describes the processes.

top - 14:02:31 up 12 days,  3:14,  2 users,  load average: 0.52, 0.58, 0.59
Tasks: 213 total,   1 running, 212 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.1 us,  1.2 sy,  0.0 ni, 95.4 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7936.4 total,    412.8 free,   3120.6 used,   4403.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   4411.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1421 www-data  20   0  412536  58204  32120 S   2.3   0.7   1:12.44 nginx

Field	What it means
/	Time spent on user processes and on kernel work
	User processes that have been reniced
	Idle
	Waiting on storage. A high figure means disk, not CPU, is the limit
/	Hardware and software interrupts
	Steal: time your VM asked for and the host gave to someone else
	Disk cache. The kernel gives it back on demand, so it is not lost
	What a new program could take without swapping. The number to watch
/	Scheduling priority and nice value (-20 greediest, 19 politest, realtime)
	Everything mapped, including memory never touched. Usually not worth reading
	Physical RAM the process is actually holding
	The part of RES shared with other processes, mostly libraries
	State: running, sleeping, stuck in IO, zombie, stopped, idle
	Share of one core, so 400 means four cores fully busy
	RES as a share of total RAM
	CPU time used since the process started, to hundredths of a second

A one-off snapshot of the same columns comes from ps.

Load Average

Three counts of processes running or waiting, averaged over 1, 5 and 15 minutes. Not a percentage.

Reading	What it tells you
	Your core count. Load is only meaningful against this
on 4 cores	Mostly idle
on 4 cores	Fully used, nothing queued yet
on 4 cores	Three deep in the queue; everything feels slow
	Rising. It is getting worse
	Falling. The spike has passed
	The same three numbers without opening top
	Raw values plus running and total task counts
	Load plus who is logged in and what they are running

Linux counts processes in uninterruptible sleep as load, so a hung NFS mount or a dying disk can show load 15 with the CPU idle. When the numbers look wrong, read and the states first.

Sorting in top

Key	What it does
	Sort by memory ()
	Sort by CPU (), the default
	Sort by total CPU time ()
	Sort by PID
	Reverse the current order
/	Move the sort to the column left or right
	Highlight the sorted column so you can see which one it is
	Field editor: move to any column and press to sort on it
	Save the sort and layout so the next starts this way

From the command line: , , or to sort smallest first.

Watching One Process

Command	What it does
	Just this PID
	Several PIDs, up to 20
	Every PID belonging to one program
	One user's processes ( matches any of the four user IDs)
	Find the PIDs first, with their command lines
then	Filter the live list to busy processes; clears filters
then	Filter by program name
	One usable CPU reading for a PID, for a script

Per-Core CPU

In the default Irix mode is a share of a single core, so a threaded process on a 16 core box can legitimately read 1600.

Key	What it does
	Switch between one summary line and one line per core
	Cycle the CPU display: text, bar, block, off
	Irix mode off, so is divided by the core count and tops out at 100
	Show threads instead of processes
	Sockets, cores and threads, when the core count itself is the question

htop draws one bar per core with no key to press, which is the usual reason people install it.

Batch Mode

turns off the interactive screen and prints plain text. It is the only way to pipe or redirect top, and htop has no equivalent.

Command	What it does
	One full sample to standard output
	Header plus the first few processes
	The biggest memory users
	Only the lines for one program
	Stop the column being cut at the terminal width
	One user's processes, into a file
	A sample a minute for a day

# Top five memory users as plain lines, for a cron report
top -b -n 1 -o %MEM -w 512 | sed -n '8,12p'

# CPU for one process, sampled properly
top -b -n 2 -d 1 -p 1234 | tail -1

The first sample of is measured since boot, so a single run understates a busy process. Ask for two iterations and read the last. For a one-shot list without any of this, is simpler (ps).

Refresh Rate

Command or key	What it does
	Refresh every 5 seconds
	Fractional delays are allowed
or , then a number	Change the delay while top is running
	Refresh immediately
	Save the delay to so it sticks
	htop counts in tenths of a second, so this is 1.5 seconds
	htop's update interval, saved with the rest of the settings

A slower refresh is worth setting on a busy server: top itself shows up in its own list, and a half-second delay on a few thousand processes is real work.

htop Keyboard Shortcuts

Function keys do everything, and the letter next to them works when a terminal or SSH client swallows F-keys.

Key	Also	Action
		Help, including the colour legend
		Setup: meters, colours, columns, display options
		Search: jump the cursor to a matching process
		Filter: hide everything that does not match
		Tree view
		Choose the sort column
		More CPU: nice -1 (root only)
		Less CPU: nice +1
		Kill the selected or tagged processes
		Quit
		Tag a process; untags everything
		Tag a process and all of its children
	/ /	Sort by memory, CPU, time
		Invert the sort order
		Pick a user from a list
		Show or hide userland threads
		Show or hide kernel threads
		Show the full path of each program
		Follow the selected process as the list reorders
		Set CPU affinity
		Set IO priority
		List the files the process has open (needs )
		Trace its system calls (needs )
		Show its environment variables
		Redraw a corrupted screen

htop Colours

Every meter is stacked, so each colour is a different kind of use rather than a different process.

Colour	Meter	What it counts
Green	CPU	Normal user processes
Red	CPU	Kernel time: system calls, drivers, interrupts
Blue	CPU	Low priority work, meaning a positive nice value
Cyan	CPU	Virtualisation: steal and guest time
Green	Memory	Memory processes are actually using
Blue	Memory	Buffers
Magenta	Memory	Shared memory
Yellow	Memory	Disk cache, returned to programs as soon as they need it
Red	Swap	Swap in use. Any sustained figure here is worth chasing

In the process list, a green name is a userland thread ( toggles them) and a red one is a kernel thread (). Memory figures above a gigabyte are shaded differently, so a loud value only means it is large. prints the legend for your build, changes the theme, and turns colour off for a terminal that renders it badly.

Filter and Search

Search moves the cursor and keeps the whole list. Filter hides everything else and keeps updating.

Key or command	What it does
or	Search by name; again steps to the next match
or	Filter to matching processes
	Clear the filter, or leave the search
	Choose a user from a list
	Start filtered to one user
	Start with a filter already applied
	Start showing only these PIDs
	Start sorted by a column from

Tree View

Key or command	What it does
or	Toggle the tree: children indented under their parent
/	Collapse or expand the branch under the cursor
	Collapse or expand every branch
	Start in tree view
	Make it the default
then	Tag a parent with its children, then kill the whole branch
	The same picture as a one-off, without htop

Kill and Renice

Key or signal	What it does
or	Kill menu: choose the signal, sends it
(15)	The default and the right first attempt: asks the process to stop
(9)	Cannot be caught or ignored, no cleanup. Use when 15 did nothing
(1)	Most daemons reload their config instead of dying
then	Tag several processes and kill them in one go
/	Nice down or up by one. A lower number gets more CPU
	Needed to signal another user's processes and to raise priority
	No kill, no renice. Safe for a screen someone else is watching

A process in state ignores because it is inside a kernel call, usually waiting on storage; fix the IO, or reboot. A service that comes straight back was restarted by systemd, so stop the unit instead (systemctl).

htop Options

Option	What it does
	Only this user
	Only these PIDs
	Update every 1.5 seconds (tenths of a second)
	Tree view
	Sort by a column
	Start with a filter
	No colour
	Ignore the mouse
	Disable kill and renice
	Version
	Every option

Settings are written to when you quit, and overwritten there each time, so editing the file while htop is open achieves nothing.

rm ~/.config/htop/htoprc   # go back to the default layout

Installing htop

System	Command
Debian, Ubuntu
Fedora, RHEL 8+, Rocky, Alma
CentOS 7
Arch
Alpine
openSUSE
macOS
FreeBSD

Inside a slim container image, run the package index update first (), and expect no htop at all in a distroless image. On RHEL 7 and older clones htop lives in EPEL, not the base repos.

top vs htop

	top	htop
Already installed	Yes, part of procps-ng	No, one package away
Mouse	No	Yes, including click a header to sort
Per-core display	toggles text lines	Bars, shown by default
Search and filter	Filter expressions with	search, filter
Tree view
Kill	, then type the PID	on the row you are on
Several at once	No	Tag with , kill them together
Scripting		Nothing, it is interactive only
Settings	writes	Saved on exit to

Both read , so the numbers agree. For containers, is the equivalent view (Docker).

Gotchas

reports almost no CPU for a busy process, because the first sample is averaged since boot. Ask for and read the last block.
is seconds, is tenths of a second. redraws twice a second and eats CPU doing it.
Load average counts processes stuck in uninterruptible sleep, so storage trouble shows up as load with an idle CPU. Read and the column before blaming the CPU.
Adding up gives a figure larger than your RAM, because shared libraries are counted in every process that maps them. Trust , not .
means your local terminal sent a value the server has no terminfo entry for. Run , or install the package on the server.
Killing a service from htop usually just restarts it, because systemd is watching. Stop the unit with systemctl, and read journalctl to find out why it was eating the CPU.

htop Commands