HTOP

htop is an interactive, real-time process viewer for Linux. It helps you quickly understand CPU load, memory pressure, swap usage, and which processes or threads are responsible. In WordPress VPS operations, it is used daily to diagnose slow sites, validate tuning changes (PHP-FPM/LSAPI, MySQL/MariaDB, Redis), and safely intervene when a runaway process threatens stability.

Background and history

Linux administrators historically used top for real-time process monitoring, but top can be harder to read and navigate under pressure. htop emerged as a more usable alternative: colorized meters, interactive sorting, easy search/filtering, and straightforward actions (kill, renice) without memorizing complex commands.

Adoption and where it’s commonly used

htop is widely used on:

• VPS and cloud Linux servers (Ubuntu/Debian, RHEL-based, Alpine)
• Web stacks (WordPress with OpenLiteSpeed/Apache/Nginx + PHP-FPM/LSAPI)
• Database and cache servers (MariaDB/MySQL, Redis)
• Incident response workflows (triage CPU spikes, memory exhaustion, runaway jobs)

Maintained by

• Maintained by the htop project community.

Best when to use

• You need fast, interactive triage during an incident (high CPU, OOM risk, slow responses).
• You want to identify the top CPU/memory consumers without scripting.
• You want to inspect process trees (parent/child relationships).
• You need to renice or stop a process safely after verification.

Not suitable when

• You need historical trends or long-term analysis (use metrics systems such as node exporters and dashboards).
• You need detailed per-query/per-request profiling (use slow logs, APM, tracing).
• You need automation-friendly output (use ps, pidstat, top -b, or sar).

Compatibility notes

• Available on most distributions, but may not be installed by default.

• Names of web/database processes vary by stack:

  • OpenLiteSpeed often uses lsphp processes rather than php-fpm
  • PHP-FPM processes are commonly php-fpm, php-fpm8.x, or pool worker names
  • MariaDB is often mariadbd; MySQL may be mysqld

• In containers, htop only shows processes visible in the container namespace, not the host.

Installation

Debian/Ubuntu

sudo apt update
sudo apt install htop

RHEL/CentOS/Rocky/AlmaLinux

sudo dnf install htop

Older RHEL/CentOS (legacy)

sudo yum install htop

Alpine

sudo apk add htop

Launch and exit

htop

Exit with q.

Useful launch variants:

# Start sorted by CPU
htop --sort-key PERCENT_CPU

# Show only a specific user (example: typical web user)
htop -u www-data

# Start in tree view
htop -t

Interface map

htop is typically divided into three areas:

Area	What it shows	Why it matters
-	--
Header meters	CPU cores, memory, swap, load average, uptime	Immediate health signals and saturation risk
Process list	Processes/threads, user, CPU%, MEM%, time, command	Identify culprits and verify what’s running
Footer keys	Function-key shortcuts	Fast actions: sort, filter, tree view, kill, renice

Key metrics to interpret for WordPress operations

CPU utilization

What to watch:

• A single process pegging one core (near 100% CPU on a single thread).
• Many worker processes each using moderate CPU (stack under heavy load).

Interpretation tips:

• On multi-core systems, overall CPU “room” is the sum of cores.
• A 4 vCPU host can show 400% total usage across processes (depending on htop display mode).

Common WordPress-related CPU culprits:

• PHP workers (php-fpm, lsphp) stuck in loops or slow plugin code
• Database (mariadbd/mysqld) due to heavy queries
• Backup/compression tasks (tar, gzip, zip)
• Malware scanning or scheduled jobs (cron, wp-cron triggers)

Memory (RAM) and RES/VIRT

• RES (Resident memory): the real RAM currently used by the process.
• VIRT (Virtual memory): address space reserved; can be large and not equal to actual RAM usage.

Operational guidance:

• Prioritize RES when investigating memory pressure.
• Large VIRT alone is not necessarily a problem.

WordPress-focused memory culprits:

• MariaDB buffer pool too large for the host
• Redis using more memory than expected (no eviction policy or large object cache)
• PHP workers with large per-request memory usage (heavy plugins, imports, image processing)

Swap usage

Swap is disk-backed memory and is much slower than RAM.

• Low swap usage can be acceptable on some systems.
• Sustained or rapidly increasing swap usage often indicates memory pressure that will degrade performance.

If swap is growing:

• Expect slower PHP and DB response times.
• Risk of OOM conditions if memory keeps climbing.

Load average

Load average indicates how many tasks are:

• Running on CPU, or
• Waiting to run (runnable queue), or
• Waiting on I/O (depending on kernel reporting and workload)

Rule of thumb:

• Compare load to the number of CPU cores.
• If load is consistently higher than core count, the system is saturated or bottlenecked.

Example:

• 4 vCPU host: sustained load above ~4 indicates consistent queuing.

Load is not only CPU

A high load average can be driven by I/O waits (disk saturation) as well as CPU saturation. Correlate with process states and disk I/O tools when needed.

Process states and what they suggest

In the process list you may see state letters (depending on configuration):

State	Meaning	Common implication
--		--
R	Running	Actively using CPU
S	Sleeping	Waiting; usually normal
D	Uninterruptible sleep	Often I/O wait; disk issues can cause this
Z	Zombie	Child exited; parent not reaped (usually minor unless many)

If many tasks are in D state, investigate storage and filesystem health.

Essential keyboard controls

These are the most useful in daily operations:

Action	Key
--	--
Help	F1
Setup (columns, meters, display)	F2
Search	/
Filter (type to match command)	F4
Tree view	F5
Sort	F6
Kill (send signal)	F9
Renice (change priority)	F7 / F8
Quit	q

Practical workflow:

1. Sort by CPU (F6 → PERCENT_CPU) or memory (F6 → RES).
2. Search (/) for php, lsphp, mariadbd, redis.
3. Use tree view (F5) to understand parent/child groups.

WordPress daily workflows

Identify PHP worker saturation

Symptoms:

• Site slow, CPU elevated, many PHP workers.

In htop:

• Sort by CPU (F6 → PERCENT_CPU)

• Search (/) for one of:

  • php-fpm
  • lsphp
  • php

What to conclude:

• Many PHP workers active with high CPU suggests request pressure or slow code.
• One worker pegged suggests a stuck request or loop.

Safe follow-up commands (read-only first):

# Confirm the service and status
systemctl status php*-fpm 2>/dev/null || true
systemctl status lsws 2>/dev/null || true

# Check recent service logs (adjust unit names)
journalctl -u php8.2-fpm -n 200 --no-pager 2>/dev/null || true
journalctl -u lsws -n 200 --no-pager 2>/dev/null || true

If you suspect a specific site pool is overloaded (PHP-FPM):

• Ensure pools are configured correctly and not allowing unbounded growth.

Investigate MySQL/MariaDB spikes

In htop:

• Sort by CPU or RES
• Search for mariadbd or mysqld

Interpretation:

• High CPU: expensive queries, missing indexes, heavy wp-cron, high traffic, or attacks.
• High RES: buffer pool and caches; may be too large for available RAM.

Safe follow-up (read-only):

systemctl status mariadb 2>/dev/null || systemctl status mysql 2>/dev/null || true

If available in your environment, use database-native tools and slow query logs to pinpoint causes rather than killing the DB process.

Avoid killing the database during normal operations

Killing mariadbd/mysqld can corrupt operations in progress and cause downtime. Prefer controlled restarts during maintenance windows after identifying the cause.

Detect WP-Cron abuse

In htop:

• Search for wp-cron
• Also watch for repeated short-lived PHP processes

Typical pattern:

• Frequent wp-cron hits can create bursts of PHP work and DB queries.

Operational approach:

• Prefer disabling pseudo-cron and scheduling a real system cron to run wp-cron at a controlled interval.

WP-Cron mitigation should be validated

Before disabling wp-cron, confirm the site’s scheduled tasks can run under an OS cron schedule appropriate for your workload.

Redis memory pressure

In htop:

• Search for redis
• Sort by RES

Interpretation:

• Redis memory should be bounded by configuration (maxmemory) and eviction policy where appropriate.
• Unbounded Redis growth can push the host into swap and slow everything.

Safe follow-up (read-only):

systemctl status redis 2>/dev/null || systemctl status redis-server 2>/dev/null || true

Sorting strategies for fast triage

Find CPU hotspots

• F6 → PERCENT_CPU
• Look for top processes and their command lines.
• Switch to tree view (F5) to see groups of workers.

Find memory pressure causes

• F6 → RES

• Look for large RES consumers:

  • mariadbd/mysqld
  • redis-server
  • many PHP workers collectively using RAM

Filter to reduce noise

• F4 and type a substring:

  • php
  • lsphp
  • maria
  • redis
  • cron

Safe process intervention: renice before kill

When a process is harmful but not clearly safe to terminate, reduce its priority first.

Renice a process

1. Select the process
2. Press F7 (higher priority) or F8 (lower priority), depending on your htop mapping and configuration
3. Prefer lowering priority for non-critical batch jobs competing with web traffic (backups, compression)

Read-only verification:

ps -o pid,ni,pri,comm -p <PID>

Kill a process safely

Use F9 and choose signals carefully:

Signal	When to use	Risk
--	-
SIGTERM (15)	Ask the process to exit gracefully	Lowest risk
SIGKILL (9)	Force stop when it will not terminate	Highest risk

Recommended escalation:

1. Try SIGTERM and observe.
2. Use SIGKILL only if the process is confirmed non-critical or is actively damaging system stability.

High-risk targets

Avoid killing these unless you have a recovery plan and understand the impact: sshd, mariadbd/mysqld, lsws/nginx/apache2, php-fpm master processes. Prefer controlled service actions with systemctl during maintenance windows.

WordPress go-live health checks using htop

Use this checklist during onboarding, after tuning changes, and during peak traffic verification.

Check	What “good” looks like	What to do if not
	--	-
Load average vs cores	Sustained load at or below core count	Identify CPU vs I/O bottleneck; reduce work, add caching, scale
Swap usage	Near-zero or stable and low	Reduce memory pressure; tune MySQL/Redis/PHP limits; add RAM
PHP workers	Not permanently saturated	Investigate slow requests, plugins, caching, PHP-FPM/LSAPI settings
DB usage	Not constantly top CPU/RES	Enable slow logs, optimize queries/indexes, tune buffers
Redis	Bounded and stable memory	Set maxmemory/eviction policy; verify object cache behavior
No runaway processes	No single task permanently pegging CPU	Profile workload, stop the offending job safely

Troubleshooting matrix

Symptom in htop	Likely cause	Safe next steps
	-	--
CPU high, many PHP workers	Traffic spike, slow plugins, uncached pages	Verify caching, check access logs, review PHP-FPM/LSAPI limits
CPU high, DB is top	Expensive queries, missing indexes, wp-cron loops	Enable/inspect slow query log, check cron behavior
Memory high, swap rising	Over-allocated MySQL/Redis/PHP, memory leak	Lower allocations, restart services safely, add RAM if needed
Load high but CPU not maxed	I/O wait, disk bottleneck	Look for D states, check disk I/O with iostat/vmstat
Many short-lived PHP processes	wp-cron, brute force, misbehaving plugin	Rate-limit, protect wp-login, move cron to system cron
Zombies accumulating	Parent process not reaping	Usually harmless unless many; restart parent service if needed

Practical lab: baseline and change verification

Run htop and record baseline during:

• Idle/normal traffic
• Plugin bulk update
• Theme switch
• Backup job (WP-CLI or filesystem backup)

Track:

• Peak CPU and which processes caused it
• Peak RES and whether swap increased
• Load average during the event
• Recovery time back to baseline

Quick command reference

Goal	Command
	-	--
Launch	htop
Start with tree view	htop -t
Filter user processes	htop -u www-data
Top memory consumers	`ps aux --sort=-%mem	head`
Top CPU consumers	`ps aux --sort=-%cpu	head`
Check service status	systemctl status <service>
View recent logs	journalctl -u <service> -n 200 --no-pager

Daily operator cheat sheet

Use this pattern when something feels slow:

1. htop → F6 → CPU%
2. Identify the top process group (PHP, DB, Redis, backups).
3. F5 tree view to confirm relationship (master/worker).
4. If needed, F6 → RES to confirm memory pressure sources.
5. Renice batch jobs before kill.
6. Prefer systemctl restart <service> only after confirming impact and having a recovery path.