How to Find and Kill High Resource Processes on Ubuntu Server

By VPS.DO
February 19, 2026

High CPU or memory usage on Ubuntu Server often stems from runaway applications, poorly optimized services (e.g., PHP workers, databases, Java processes, browsers in containers), fork bombs, or memory leaks that trigger the kernel’s Out-Of-Memory (OOM) killer. Identifying and safely terminating these processes restores performance without rebooting the system.

Ubuntu provides a layered set of tools ranging from basic built-ins to interactive viewers. The goal is to first identify the culprit(s) by resource consumption (CPU %, memory RSS/VSZ, threads), then terminate them gracefully when possible, falling back to forceful termination only when necessary.

1. Quick Identification – Built-in Tools

top — the classic real-time process monitor (pre-installed)

Bash

top

Sorts by CPU % by default (press Shift + P to confirm)
Memory usage shown in RES (resident) and %MEM columns
Press Shift + M to sort by memory instead
High iowait (%wa) often hides behind low user/system CPU — indicates I/O-bound rather than CPU-bound problem
Press k → enter PID → choose signal (15 = TERM graceful, 9 = KILL forceful)

uptime & vmstat — quick health check

Bash

uptime                  # high load average with low CPU → likely I/O or D-state
vmstat 1 5              # look at high 'si/so' (swap), 'wa' (iowait), 'r' (runnable)

2. Preferred Interactive Tool – htop (strongly recommended)

Bash

sudo apt update && sudo apt install htop
htop

Advantages over top:

Color-coded bars for CPU/memory/swap per core
Scrollable process list with full command lines (press F2 → Display options → Detailed CPU time)
Tree view (F5) shows parent-child relationships (very useful for forking services)
Sort by any column (F6) — CPU%, MEM%, TIME+, NLWP (threads)
Kill directly: highlight process with arrows → F9 → select signal (TERM first, then KILL if needed)
Search (F3) by name/command
Mouse support in most terminals

Common workflow in htop:

Press F6 → sort by PERCENT_CPU or PERCENT_MEM
Look for processes >50–80% sustained usage or rapidly growing memory
Highlight → F9 → 15 (SIGTERM) first → wait 5–10 s → if still alive → 9 (SIGKILL)

3. Non-Interactive / Scripting Approaches

ps — snapshot of processes (useful in scripts or when htop/top is unavailable)

Bash

# Top 10 CPU consumers
ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -n 11

# Top 10 memory consumers (RSS in MB)
ps -eo pid,ppid,rss,%mem,cmd --sort=-rss | head -n 11 | awk '{print $1,$2,$3/1024 " MB",$4,$5}'

# All processes owned by a user eating resources
ps -u www-data -o pid,%cpu,%mem,cmd --sort=-%cpu

pkill / killall — kill by name (careful — can affect multiple processes)

Bash

pkill -f "python.*manage.py"          # pattern match in command line
pkill -u www-data php-fpm             # all php-fpm processes of user
killall -9 chrome                     # forceful kill all chrome instances

4. Memory-Specific – OOM Killer Insight

When the kernel invokes the OOM killer (system becomes unresponsive or processes disappear):

Check kernel logs: dmesg | grep -i ‘out of memory’ -A 5 or journalctl -k | grep -i oom
Look for lines like: Out of memory: Killed process 12345 (mysqld)
The OOM killer scores processes based on memory usage, runtime, oom_score_adj, etc. — higher score = more likely to be killed
View current OOM score of a process: cat /proc/<PID>/oom_score

To protect important services from OOM killer:

Bash

# Lower score (less likely to be killed)
echo -1000 | sudo tee /proc/<PID>/oom_score_adj

5. Safety & Best Practices

Always prefer SIGTERM (15) over SIGKILL (9) — gives the process a chance to clean up (close connections, flush buffers)
Avoid kill -9 as first choice — can corrupt databases, leave temporary files, or break socket connections
Check parent process (PPID column or htop tree view) — killing a child may not solve the problem if the parent respawns it
Use service restart when possible: sudo systemctl restart nginx instead of killing processes directly
Monitor trends — install netdata (bash <(curl -Ss https://my-netdata.io/kickstart.sh)) or glances for historical view and alerts
Prevent recurrence — tune limits (ulimit, systemd service files), enable zram/swap, profile applications (perf, strace)

Quick Decision Flow

Run htop (or top) → sort by CPU% or MEM%
Identify top 2–5 offenders (look at command, user, threads)
Try graceful stop (service restart or SIGTERM)
If unresponsive → SIGKILL
Watch for respawn → check systemd unit or cron
Check logs (journalctl -u <service> -xe) for root cause

Most high-resource issues on Ubuntu Server resolve within 30–60 seconds using htop + targeted kill/restart. Persistent problems usually require application-level fixes (query optimization, connection pooling, rate limiting) rather than repeated killing.

If you share symptoms (high CPU with low usage, memory ballooning, service name, htop screenshot description, or top output snippet), more precise diagnosis and safe termination steps can be provided.

How to Find and Kill High Resource Processes on Ubuntu Server