Using the top Command to Monitor Linux Processes
Learn how to use top on Linux to monitor live process activity, interpret CPU and memory usage, sort tasks, and safely stop a problematic process.
top is an interactive Linux utility for monitoring system activity and running processes. It displays a continuously refreshing, full-screen view of processes, CPU usage, memory usage, and task states.
A process is a running instance of a program. The top display calls each listed unit a task; depending on its configuration, a task can represent a process or a thread. This makes top useful for finding active processes, identifying resource-intensive tasks, and seeing which user owns a task.
Unlike ps, which normally produces a one-time snapshot, top keeps updating the display. A snapshot can answer “what was running when I checked?”; top can help answer “what is continuing to consume CPU or memory?”
Starting and Leaving top
Open a terminal and run:
top
top takes over the terminal with an interactive display. The summary area appears above the process list, and the list refreshes periodically.
- Press
qto quit top normally. - Press
hor?while top is running to open its in-program help.
Understanding the Summary Area
The upper part of the display summarizes system-wide activity. Exact wording and formatting can vary between Linux distributions and top versions, but the same broad ideas apply.
Task counts
The task summary commonly reports the total number of tasks and counts of tasks that are running, sleeping, stopped, or zombies.
- Running: Tasks currently running or ready to run.
- Sleeping: Tasks waiting for an event, timer, or input. Sleeping does not automatically mean a task is unhealthy.
- Stopped: Tasks paused by a signal or debugger.
- Zombie: A terminated process whose parent has not yet collected its exit status. A small, temporary number can occur normally; persistent zombies may indicate a parent-program problem.
CPU summary
The CPU summary divides processor time into categories. At a high level, these include:
- User time: CPU time spent running application code.
- System time: CPU time spent in the operating system kernel on behalf of programs.
- Idle time: CPU capacity that is not currently being used.
- I/O wait: Time the CPU spends waiting for input or output operations to complete, such as storage activity.
High user or system time can indicate active computation. High I/O wait can point toward storage or other I/O delays rather than a program simply needing more CPU.
Memory and swap summaries
The memory lines show physical RAM totals and usage, often including free, used, and available memory. Swap information shows how much configured swap space is used. These figures help assess memory pressure, but Linux may use otherwise idle RAM for caches, so “used” memory alone is not proof of a problem.
Interpret the summary and process list together. For example, a high-CPU process is more significant when CPU idle time is low and the system is slow. A memory-heavy process deserves closer attention when available memory is low or swap activity is increasing.
Reading the Process List
Each row represents one task. The following columns are commonly visible in the default display.
| Column | Meaning | How to use it during diagnosis |
|---|---|---|
| PID | Process ID, the numeric identifier for the task. | Use it to distinguish the exact process and to target an operation such as signaling. |
| USER | The account that owns the process. | Confirm whether the task belongs to you, another user, or a system service. |
| PR | The scheduler priority associated with the task. | Provides context about scheduling priority; do not change it without understanding the effect. |
| NI | The nice value, a scheduling adjustment. | Higher nice values generally make a task less favored for CPU time. |
| VIRT | Virtual memory address space associated with the process. | Shows the address space mapped or reserved by the task, not necessarily physical RAM in use. |
| RES | Resident memory: physical RAM currently used by the process and not swapped out. | Use it with %MEM to assess immediate physical-memory consumption. |
| %CPU | The proportion of CPU time attributed to the task. | Use it to locate active or CPU-intensive work, then observe whether the value persists. |
| %MEM | The proportion of physical memory used by the task. | Use it to locate processes consuming a large share of RAM. |
| COMMAND | The executable or command associated with the task. | Identify what the process is doing and whether it is expected. |
VIRT versus RES: virtual memory is an address-space measurement. It can include mapped files, shared libraries, reserved regions, and memory that is not currently resident in RAM. RES is closer to the process's current physical-memory footprint, although shared memory can make ownership and totals more complicated.
High %CPU or %MEM is an investigation indicator, not automatic proof of a fault. A compiler, backup, media job, database query, or other legitimate workload may temporarily use substantial resources.
Sorting Processes
The process list is normally ordered by CPU utilization. Sorting changes the question you are asking: CPU sorting finds active computation, while memory sorting finds tasks with larger physical-memory footprints.
| Key | Action | Typical use |
|---|---|---|
P | Sort by CPU usage. | Find the tasks currently using the most CPU. |
M | Sort by memory usage. | Find tasks with the largest %MEM values. |
R | Reverse the current sort direction. | Inspect the opposite end of the selected field. |
< | Move the active sort field left among available columns. | Choose a different column as the sort field. |
> | Move the active sort field right among available columns. | Choose a different column as the sort field. |
k | Prompt for a PID and send a signal. | Request that a selected process terminate or otherwise respond. |
h or ? | Open interactive help. | Review available commands and display controls. |
q | Quit top. | Return to the shell. |
| Sort choice | Primary indicator | Question answered | Follow-up details to check |
|---|---|---|---|
| CPU sort | %CPU | Which task is consuming processor time? | PID, USER, COMMAND, duration of high usage, and whether the work is expected. |
| Memory sort | %MEM and RES | Which task is using the most physical memory? | Available memory, swap, VIRT versus RES, process purpose, and whether usage is growing. |
Finding a Resource-Consuming Process
CPU investigation
- Run
top. - Press uppercase
Pto order the process list by CPU usage. - Inspect the leading rows. Record the
PID,USER,%CPU, andCOMMAND. - Watch several refreshes. A brief spike may be normal; sustained high usage is more useful evidence.
- Determine whether the command is expected and whether it belongs to you, another user, or a system service.
A process near the top of the CPU list may be CPU-bound, stuck in a loop, doing legitimate work, or serving active demand. Confirm the command and owner before taking action. If the system is slow but no one process dominates, inspect the summary for low idle time, I/O wait, memory pressure, swap use, or many runnable tasks.
Memory investigation
- Run
topand press uppercaseM. - Compare
RESand%MEMfor the leading rows. - Use
COMMAND,PID, andUSERto identify the task and its owner. - Compare the process figures with the memory and swap summary.
- Press
Pto return to CPU-based ordering when needed.
A high VIRT value with comparatively low RES does not necessarily mean that the process is consuming the same amount of physical RAM. Use RES and %MEM when assessing immediate RAM consumption.
Stopping a Process from top
top can send an operating-system signal. A signal is a notification that requests a process to terminate or change behavior.
- Confirm the target's
PID,USER, andCOMMAND. Do not rely on position alone because the list can change between refreshes. - Press
k. - When prompted, enter the process ID and press Enter.
- Choose an appropriate signal according to your local policy and the process state.
- Observe the refreshed list to verify that the process exits or changes state.
The usual graceful termination request is SIGTERM, commonly signal 15. It gives a well-behaved program an opportunity to close files, save state, and clean up. A more forceful option is SIGKILL, commonly signal 9. The kernel ends the process without allowing it to handle cleanup, so unsaved work may be lost and resources may require recovery.
Permissions and Safe Operational Practice
- You can normally manage processes owned by your own account.
- Signaling another user's process or a system service may require elevated privileges and authorization.
- Attempt graceful shutdown before forceful termination whenever appropriate.
- If the same process repeatedly consumes resources, investigate its configuration, workload, logs, dependencies, or application bug instead of repeatedly killing it.
- Do not terminate system-critical processes unless you understand their role and the consequences.
Ownership is an important part of diagnosis. For background on Linux file and resource ownership concepts, see Manage File Ownership. You can also return to the Linux command-line guide for related terminal topics.
Practical Workflows
Inspect current processes
- Run
topin a terminal. - Observe the summary area and the process rows as they refresh.
- Press
qto exit.
This demonstrates the difference between a live monitor and a static process listing.
Reverse the current order
- Press
PorMto choose CPU or memory sorting. - Press
Rto reverse the order. - Press
Ragain to restore the previous direction.
Stop an unresponsive high-CPU task
- Sort by CPU with
Pand wait through multiple refreshes. - Confirm the PID, owner, and command.
- Press
k, enter the verified PID, and select a suitable termination signal. - Allow graceful termination time before considering a forceful signal.
- Confirm the outcome in top and investigate why the task became unresponsive.
Troubleshooting Interpretations
| Symptom | Likely interpretation | Recommended response |
|---|---|---|
| A process moves near the top of the CPU list, then drops quickly. | The activity may be short-lived or expected. | Observe several refresh cycles and check PID, USER, and COMMAND before acting. |
| A process appears to use most of the CPU. | It may be CPU-bound, stuck, performing legitimate work, or serving active demand. | Confirm the owner and command, assess whether the workload is expected, and inspect application or service logs. |
| A process has high VIRT but low RES. | Its virtual address space is large, but it is not using the same amount of physical RAM. | Use RES and %MEM to assess immediate physical-memory consumption. |
| A termination request does not stop a process. | The signal may be handled or delayed, the task may be waiting on an uninterruptible operation, or permissions may be insufficient. | Verify the PID, ownership, and privileges; allow graceful shutdown time; escalate only when the consequences are understood. |
| The current user cannot signal a process. | The process belongs to another account or requires administrative privileges. | Use an authorized administrative workflow. |
| The system feels slow but no process has an extreme CPU value. | The issue may involve memory pressure, I/O wait, many runnable tasks, or aggregate load. | Review task counts, idle and I/O-wait CPU time, memory and swap figures, and memory sorting. |
Key Takeaways
topprovides a continuously refreshing view of system activity and running tasks.- Use
Pfor CPU investigation andMfor memory investigation. - Use PID, USER, COMMAND, and the resource columns together to identify a task safely.
- Compare the process list with the summary area before concluding that the system has a fault.
- Use
kcarefully: prefer graceful termination and verify the PID before signaling. - Persistent high usage should lead to investigation, not repeated process termination.