Atop

Atop is an advanced system and process monitor for Linux that can show real-time resource usage and also record historical performance snapshots for later analysis. Unlike top/htop, which are primarily “live only,” Atop can run in logging mode to capture CPU, memory, disk, and network activity over time. This makes it especially useful for troubleshooting intermittent WordPress VPS issues where the problem happens before you log in.

Background and history

Traditional Linux monitoring tools focused on real-time visibility, which works well when you can reproduce a problem on demand. As VPS workloads became more bursty (cron jobs, backups, traffic spikes), administrators needed lightweight “flight recorder” tools that could capture short-lived incidents. Atop became a popular choice because it records per-interval system and process statistics while remaining relatively lightweight compared to full observability stacks.

Adoption and where it’s commonly used

Atop is commonly used for:

• VPS and dedicated servers where you need historical performance data
• Root-cause analysis of spikes (CPU bursts, memory pressure, I/O saturation)
• Post-incident investigation (what happened overnight)
• Capacity planning based on trends over hours/days

Maintained by

• Maintained by the Atop project community.

Best when to use

• You need both live monitoring and historical playback.
• You troubleshoot intermittent issues (site slow at night, random CPU spikes).
• You want per-process history to identify which program caused a spike.
• You want a lightweight recorder without running a full metrics stack.

Not suitable when

• You need centralized dashboards and multi-host correlation (use Prometheus/Grafana or similar).
• You need high-resolution tracing or profiling (use perf, eBPF tools).
• You cannot store local logs (disk space constraints) or you do not rotate logs properly.

Compatibility notes

• Available on most Linux distributions; package name is typically atop.
• Logging behavior depends on how the distro configures the atop service.
• Recorded files are stored locally (commonly under /var/log/atop/), so disk space and log rotation matter.
• Some environments require enabling the atop service/timer explicitly.

Concepts and how it works

Atop collects system and process stats at intervals and can:

• display the current snapshot (interactive UI)
• write snapshots to binary log files
• replay snapshots later, including per-process details

Installation

Debian/Ubuntu

sudo apt update
sudo apt install -y atop

RHEL/Fedora/Rocky/AlmaLinux

sudo dnf install -y atop

Start and use Atop (live mode)

Run:

sudo atop

Exit:

q

Run as root for full visibility

Atop can show more complete per-process information when run with elevated privileges.

Enable historical logging

On many distros, installing atop also installs a service or timer that records snapshots automatically. Verify and enable it explicitly.

Check service/timer status

systemctl list-unit-files | grep -E '^atop(\.service|\.timer)\b' || true
systemctl status atop 2>/dev/null || true
systemctl status atop.timer 2>/dev/null || true

Enable if present

If your system uses a timer:

sudo systemctl enable --now atop.timer

If your system uses a service:

sudo systemctl enable --now atop

Confirm logs exist:

ls -la /var/log/atop 2>/dev/null || true

Distro differences

Some distributions log to /var/log/atop/atop_*, others use a different naming convention. Use ls /var/log/atop to confirm the actual layout on your host.

Replay historical data (the key feature)

List available logs

ls -1 /var/log/atop 2>/dev/null || true

Replay a specific day

Example (adjust filename to match your host):

sudo atop -r /var/log/atop/atop_$(date +%Y%m%d)

Jump to a specific time

sudo atop -r /var/log/atop/atop_$(date +%Y%m%d) -b 10:00

You can then navigate through intervals interactively.

Key views and controls

Atop has many toggles. The following are commonly used for WordPress VPS operations.

High-signal areas to watch

Area	What it reveals	WordPress relevance
--	-
CPU usage	user/system/iowait/steal	PHP spikes, noisy neighbors
Memory	RAM pressure, cache, swap	plugin bursts, DB buffers
Disk	utilization, I/O rates	backups, DB flush spikes
Network	RX/TX throughput	bot traffic, CDN bypass
Per-process	offenders by CPU/mem/disk	identify lsphp, php-fpm, mariadbd

Common interactive keys (varies slightly by version)

Action	Typical key
-
Help	h or ?
Quit	q
Process view	t (often toggles process-related detail)
Disk view	d
Network view	n
Memory view	m
Refresh interval	i

Key bindings vary

Atop key bindings can differ by version/distribution. Use the built-in help (h/?) to confirm the exact keys on your system.

Practical use cases (WordPress VPS)

Use case 1: Identify what caused a CPU spike overnight

1. Confirm logging is enabled.
2. Replay the time window:

sudo atop -r /var/log/atop/atop_$(date +%Y%m%d) -b 02:00

3. Step through intervals and identify:

• top CPU-consuming process names
• whether the spike correlates with disk I/O or network activity

Common culprits:

• php-fpm/lsphp worker storms
• mariadbd spikes during backups or heavy queries
• compression/archiving during backup jobs (tar, gzip, zip)
• malware or crypto miners (unexpected binaries)

Use case 2: Diagnose disk I/O saturation causing slow wp-admin

Replay the suspected time window and watch:

• high iowait in CPU stats
• sustained disk busy percentage
• processes responsible for writes (backups, DB flush, logs)

Validate with current tools if issue is ongoing:

sudo iotop -oP

Use case 3: Memory pressure and swap growth

Atop helps confirm whether swap growth correlates with:

• too many PHP workers
• oversized DB buffers
• memory leaks in a service
• sudden traffic spikes

Validate current memory view:

free -h
vmstat 1 5

Log retention and disk usage

Atop logs are local files. If left unmanaged, they can grow.

Check log directory size

sudo du -sh /var/log/atop 2>/dev/null || true

Check rotation policy

Depending on distro, rotation is handled by:

• logrotate
• the atop package’s built-in retention rules
• systemd timer/service configuration

Inspect relevant configs:

ls -la /etc/logrotate.d | grep -i atop || true
systemctl cat atop 2>/dev/null || true
systemctl cat atop.timer 2>/dev/null || true

Storage safety

If your VPS has limited disk space, confirm atop retention settings early. Historical logging is only useful if it does not risk filling the filesystem.

Troubleshooting

No logs are being created

Common causes:

• atop timer/service not enabled
• log directory permissions or missing directory
• package installed without logging integration

Checks:

systemctl status atop 2>/dev/null || true
systemctl status atop.timer 2>/dev/null || true
ls -la /var/log/atop 2>/dev/null || true
journalctl -u atop -n 200 --no-pager 2>/dev/null || true

Replay fails or file not found

• Confirm actual filenames in /var/log/atop/
• Use the exact file name:

sudo atop -r /var/log/atop/<file_name>

Atop shows limited per-process data

Run with sudo/root:

sudo atop

Security notes

• Atop can reveal process names, command lines, and operational activity. Treat logs as sensitive.
• If you suspect compromise, atop history can help identify unexpected processes and the time they appeared, but also preserve logs for incident response.

Quick reference

Goal	Command
Install (Debian/Ubuntu)	sudo apt install -y atop
Live view	sudo atop
Enable logging (timer)	sudo systemctl enable --now atop.timer
Enable logging (service)	sudo systemctl enable --now atop
List logs	ls -1 /var/log/atop
Replay today	sudo atop -r /var/log/atop/atop_$(date +%Y%m%d)
Replay from time	sudo atop -r /var/log/atop/atop_YYYYMMDD -b HH:MM
Check log size	sudo du -sh /var/log/atop