Reading the resource graphs in your portal — what each metric means

The Graphs tab on every VPS draws four utilization charts pulled straight from the hypervisor: CPU, memory, network, and disk. This article explains what each one shows, what's normal, and what patterns mean something's wrong (or just busy).

Where the data comes from

The hypervisor keeps an RRD time-series database for every VM. The portal queries that store directly — no agent runs inside your VPS, no instrumentation to install, no overhead in the guest. Whatever your VPS is showing externally to the hypervisor is what you see in the graphs.

Two controls above the graphs change the view:

• Timeframe: Hour, Day, Week, Month, Year. Wider timeframes are pre-consolidated by RRD (averages of averages); finer detail in shorter views.
• Consolidation: Average (typical use — what was the rate over each sample bucket?) or Maximum (peak — what was the highest single sample in each bucket?). Use Maximum when investigating spikes that an Average view would smooth out.

CPU graph

Shows CPU utilization as a percentage. 100% means one full vCPU's worth of work. If your plan has 4 vCPUs, the graph can show up to 400%.

• Steady 5-20%: idle to light workload — normal for most VPSes.
• Sustained near 100% × vCPU count: you're CPU-bound. Either the workload genuinely needs more CPU, or a process is stuck in a loop. SSH in, run top or htop, find the culprit.
• Periodic spikes: cron jobs (logrotate, backups, cert renewal), package updates, scheduled application tasks. Match the timing to your crontab.
• Sudden flatline at 100%: often an OOM-killer chain reaction (low RAM forces swap thrash; load shoots up; eventually OOM-killer reaps the offender). Check memory graph for correlation.

Memory graph

Shows RAM usage in bytes. Includes the kernel's page cache, which Linux uses to cache disk reads — "high memory usage" on Linux is usually fine because the page cache will release back to applications on demand. The number that matters is "available," not "used."

• Curve climbs over hours/days then plateaus: normal — the page cache fills up to make subsequent disk reads faster.
• Plateaus right near your plan's RAM ceiling: also normal — Linux fills available memory with cache.
• Repeated sharp drops: applications are being killed by OOM-killer, or processes are restarting. Check dmesg | grep -i kill in the VPS.
• Memory hits 100% AND swap (disk) traffic spikes simultaneously: you're swapping. Bad for performance. Either reduce memory pressure, add RAM via plan upgrade, or move workloads off.

Network graph

Shows bytes per second transmitted and received on the VPS's public interface. Two lines (TX and RX) overlay each other.

• Steady low traffic (kilobits/sec): typical for a server doing housekeeping but not serving requests.
• Bursts during specific hours: legitimate traffic from your application's users.
• Sustained line rate (close to your plan's Mbps cap): heavy outbound or a backup/sync in progress. Confirm with iftop or nethogs on the VPS.
• Sudden sustained inbound spike with no corresponding application activity: possibly a DDoS or scraper. Check ss -tn and your access logs.
• Sudden outbound spike you didn't trigger: possible compromise — VPS being used as part of a botnet or as a relay. Investigate, snapshot, possibly reload.

Disk graph

Shows read and write throughput in bytes per second.

• Background low writes: journals, logs, swap. Normal.
• Steady writes for hours: backups in progress, database flushing changes, log file growth from a chatty application.
• High reads during boot: normal — kernel, init, services all loading.
• Constant 50+ MB/s sustained: probable application doing heavy IO. SSD-backed storage handles it but consider whether it's intentional.
• Disk I/O closely tracking the memory graph decreasing: swapping. See the memory section above.

Common patterns and what they tell you

• CPU + memory + disk all spiking together for a few seconds, periodically: scheduled job (cron). Match timing to crontab -l output.
• Slow memory crawl over weeks ending in a sudden flatline: classic memory leak in a long-running process. Restart the service; investigate the cause.
• CPU 100% sustained, network 0, disk 0: looping process. top will find it; kill -9 the offender.
• Network maxed, CPU low: a static-content delivery or download in flight. Healthy unless unexpected.
• Disk writes spike at 3am every day: logrotate compressing yesterday's logs. Normal.

How to use the graphs in practice

1. Baseline first. Look at the Week or Month view when nothing's wrong, so you know what your normal looks like. Anomalies are only anomalies relative to a baseline.
2. When in doubt, switch to Maximum. Average smooths brief spikes; Maximum shows them. A 5-second 100% CPU spike is invisible in Average / Day view but obvious in Maximum / Day view.
3. Correlate across graphs. Most problems show up in two or more metrics at once. CPU only ≈ compute-bound. CPU + memory + swap ≈ memory pressure. Disk + network ≈ backup or sync.
4. Snapshot before investigating if the issue is currently happening and you might want to capture state.

If a graph is showing something you can't explain, open a ticket with the timeframe and what you were doing — we can usually correlate to hypervisor-level events (storage saturation, network blip on the host) that won't be visible in your guest.