Glances

Glances is a cross-platform, real-time monitoring tool that consolidates CPU, memory, swap, load, disk I/O, filesystem usage, network activity, and top processes into a single interactive dashboard. It is useful on WordPress VPS servers because it reduces context-switching: you can correlate performance symptoms (slow admin, high load, swap growth, I/O wait, traffic bursts) from one screen instead of running many separate tools.

Background and history

Linux monitoring historically relied on single-purpose utilities (top, free, vmstat, iostat, ss). As stacks became more complex and incidents demanded faster correlation, “unified dashboards” emerged to present multiple subsystems at once. Glances gained adoption by providing a lightweight terminal UI with optional web and API modes, making it practical for SSH-based operations and quick remote visibility.

Adoption and where it’s commonly used

Glances is commonly used in:

• VPS and cloud administration via SSH
• Web hosting stacks (WordPress with OpenLiteSpeed/Nginx/Apache, PHP-FPM/LSAPI, MariaDB/MySQL, Redis)
• Small-to-medium fleets that need an at-a-glance view without a full metrics stack
• Incident triage sessions where time-to-signal matters

Maintained by

• Maintained by the Glances project community.

Best when to use

• You want one screen to correlate CPU, memory, swap, disk, network, and processes.
• You are diagnosing unclear bottlenecks (not sure if the issue is CPU, RAM, disk, or traffic).
• You need quick threshold-based visual alerts during maintenance (plugin updates, migrations).
• You want optional web/API access for lightweight remote monitoring.

Not suitable when

• You need long-term dashboards, alerting, and retention across many servers (use a metrics/logging stack).
• You need deep per-subsystem detail (prefer iotop, iftop, pidstat, perf, or database-specific tools).
• You cannot secure the web/UI endpoints appropriately.

Compatibility notes

• Installation method affects features and version:

  • OS packages are stable but sometimes older.
  • Python/pip installs can be newer but require dependency control.

• Some metrics (temperature/sensors, containers) require extra packages or privileges.

• Web mode listens on a TCP port (default 61208) and must be firewall-restricted if exposed.

• On very small VPS instances, Glances is generally safe but still heavier than top; use it when you need correlation.

Concepts and how it works

Glances collects system metrics from the OS and presents them in a single dashboard with threshold-based coloring. It can also expose metrics via a built-in web server and API.

Installation

Debian/Ubuntu (distribution package)

sudo apt update
sudo apt install -y glances

RHEL/Fedora/Rocky/AlmaLinux

sudo dnf install -y glances

Install latest version via pip (version parity across servers)

Use this when you want consistent behavior and newer features across different distros.

sudo apt update
sudo apt install -y python3 python3-pip
python3 -m pip install --user glances

If you need it system-wide (be consistent with your ops policy):

sudo python3 -m pip install glances

Verify:

glances --version
command -v glances

Package vs pip

Avoid mixing OS package Glances and pip Glances on the same server unless you control PATH and service definitions carefully. Standardize on one approach per fleet to reduce surprises.

Run Glances

Interactive terminal mode:

glances

Exit:

q

Interface overview

Common sections and what they mean:

Section	What it tells you	WordPress relevance
--	-
CPU	total and per-core usage, steal time	PHP worker spikes, noisy neighbors in cloud
Load	runnable queue averages	overload vs vCPU count
Memory	RAM usage including cache	plugin pressure, DB buffer sizing
Swap	swap usage and activity	memory starvation indicator
Disk I/O	read/write throughput and utilization	slow DB flushes, backups, log bursts
Filesystems	disk usage by mount	capacity planning, runaway logs
Network	RX/TX throughput and errors	bot bursts, CDN bypass, abusive egress
Processes	top CPU/mem processes	find php-fpm, lsphp, mariadbd, redis-server

WordPress-focused metrics and targets

Targets depend on instance size and traffic profile, but these are useful operational thresholds for investigation.

Metric	What “good” looks like	Investigate when
--	-
Load average vs vCPU	load generally below vCPU count	sustained load > vCPU count
CPU saturation	intermittent spikes are normal	sustained near 100% for long periods
Memory usage	stable, with cache fluctuating	steady rise or frequent OOM events
Swap usage	near zero for most WP workloads	sustained swap growth or frequent swap-in/out
Disk I/O utilization	bursts during backups/updates	sustained high utilization or high iowait
Network throughput	matches expected traffic	unexpected spikes or error/drops
Top processes	expected services dominate	unknown processes or runaway workers

Interpreting memory on Linux

Linux uses free RAM as filesystem cache. High “used” memory is not always a problem. Treat swap growth, OOM kills, and sustained reclaim pressure as higher-signal indicators than raw “used” RAM.

Key bindings (daily use)

These key bindings can vary slightly by version, but the following are commonly available and useful:

Action	Key
Sort processes by CPU	c
Sort processes by memory	m
Disk I/O view	d
Network view	n
Filesystem view	f
Sensors (if supported)	s
Quit	q

Practical workflows (daily operations)

Workflow 1: Fast triage when the site is slow

1. Start Glances:

glances

2. Look at:

• Load vs vCPU
• CPU and top processes
• Swap growth
• Disk I/O spikes
• Network throughput spikes

3. Confirm the main offender process names:

• OpenLiteSpeed PHP often shows as lsphp
• PHP-FPM stacks show php-fpm and pool workers
• Database shows mariadbd or mysqld
• Redis shows redis-server

Workflow 2: Plugin update audit

Run a change in one terminal:

wp plugin update --all

Monitor in another:

glances

Watch for:

• CPU spikes (PHP workers)
• disk I/O (writes during updates)
• database activity (metadata and options writes)
• memory pressure and swap

Workflow 3: Identify wp-cron pressure

Indicators:

• repetitive bursts of PHP processes
• load rises at predictable intervals
• request spikes without user traffic

Confirm with process list and application logs. If you disable WP-Cron, replace it with a system cron schedule to avoid missed tasks.

Workflow 4: Disk bottleneck confirmation

If Glances shows high disk activity:

• Confirm with a dedicated tool (more precise):

sudo iotop -oP

If database writes dominate, prioritize DB tuning and reduce unnecessary scheduled jobs and backups during peak hours.

Workflow 5: Traffic burst / bot suspicion

If Glances shows a sudden network spike and process fork storm:

• Confirm network flows:

sudo iftop -nP

• Confirm connections:

ss -s
sudo ss -tulpen | head

Web UI mode (optional)

Start web mode (default bind)

glances -w

Default port is typically 61208.

Do not expose Glances web mode publicly

Glances can reveal system and process information. Bind to localhost and use SSH tunneling, or restrict access with firewall rules and trusted IP allowlists.

Bind to localhost only (recommended)

glances -w --bind 127.0.0.1

Access from your workstation via SSH tunnel:

ssh -L 61208:127.0.0.1:61208 -p 2581 user@server_ip

Then browse locally to http://127.0.0.1:61208.

Run Glances persistently (systemd)

Use this only if you need a long-running web/API endpoint.

Create a service file:

sudo tee /etc/systemd/system/glances.service >/dev/null <<'EOF'
[Unit]
Description=Glances (Web Mode)
After=network.target

[Service]
ExecStart=/usr/bin/glances -w --bind 127.0.0.1
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target
EOF

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable --now glances
sudo systemctl status glances --no-pager

Path differences

If Glances was installed via pip, the executable path may not be /usr/bin/glances. Use command -v glances and adjust ExecStart accordingly.

Export and reporting

Export to CSV (useful for short audits):

glances --export csv --export-csv-file /root/glances.csv

Data handling

Exported files may contain process names and system details. Store and transfer them securely.

Troubleshooting

Glances shows wrong or missing metrics

Common causes:

• Running an older packaged version
• Missing optional dependencies (sensors, Docker integrations)
• Permissions insufficient for certain readings

Checks:

glances --version
python3 -c "import psutil; print(psutil.__version__)" 2>/dev/null || true

High load but low CPU usage

Likely causes:

• Disk I/O wait or blocked tasks
• Database flush pressure
• Backup jobs running

Confirm:

iostat -xz 1 3 2>/dev/null || true
sudo iotop -oP 2>/dev/null || true

Memory looks “full” but server is stable

Likely normal Linux caching behavior. Investigate only if:

• swap grows
• OOM kills occur
• latency spikes under moderate load

Confirm OOM events:

dmesg | grep -i -E "oom|out of memory" | tail -n 50

Security notes

• Web mode must be bound to localhost or protected by strict firewall allowlists.
• Avoid sharing screenshots or exports publicly; they can reveal sensitive operational details.
• Use Glances as an observability tool, not as a control plane; make changes via controlled config management and service management.

Quick reference

Goal	Command
	-
Start interactive dashboard	glances
Start web mode (local only)	glances -w --bind 127.0.0.1
Web access via SSH tunnel	ssh -L 61208:127.0.0.1:61208 user@server_ip
Sort by CPU	c
Sort by memory	m
Disk view	d
Network view	n
Filesystems view	f
Quit	q
Export CSV	glances --export csv --export-csv-file /root/glances.csv