Peer-to-Peer Session

VPS Server Resource Troubleshooting

A practical guide to diagnosing and resolving CPU, RAM, disk, bandwidth, and malware issues on VPS servers — including when it's the client, when it's the node, and when to escalate.

01 · Foundation

VPS resources & where to check them

Every VPS has five key resources, each with its own limits and failure signals. Recognising which resource is under stress is the first diagnostic step for any performance case.

⚙️ CPU

Executes all server instructions. Sustained high usage triggers automatic throttling of −25% per hour until usage drops back under limit.

🧠 RAM

Active memory for running processes. When exhausted, visitors get 503 errors and the server may become unresponsive.

💾 Disk Space

Storage for files, databases, logs. Full disk = server failure — services stop, MySQL crashes, cPanel/hPanel behaves erratically.

📡 Bandwidth

Data transferred in/out per month. When exceeded → speed is throttled to 10 Mbps until the 1st of the next month. Server stays online.

💽 I/O — read/write speed

300 MB/s on all KVM plans. Rarely the bottleneck unless something is thrashing the disk (e.g., runaway logs, database rebuild).

📌 Key teaching point: VPS is self-managed. Always set that expectation with clients first — use predefine #vps-comm1. Optimisation of applications, code, plugins, and security is the client's responsibility. Our job is to identify the resource issue and point them to the right path.

Where to check resource usage

📊 hPanel

Backups & Monitoring → Server Usage. Graphs for CPU, RAM, Disk, Bandwidth. Client-facing view — where they see it too.

🛠️ hVPS Admin

Metrics tab — agent-side view. Also has the PROCESSES tab for spotting malware (critical for CPU cases).

🖥️ SSH

Real-time process inspection — top, htop, free -m, df -h. Where the actual diagnosis happens.

Reference How to check VPS resources usage
02 · CPU

High CPU usage

The most common VPS complaint. High CPU can be legit workload, buggy code, or malware — the diagnostic path decides everything.

Symptoms

  • Server is slow / unresponsive to SSH or HTTP
  • CPU graph hitting the red line in hPanel
  • Automatic CPU throttling has kicked in (−25% per hour)

Diagnostic steps

1
Confirm the limit is hit
hPanel → Server Usage. Is CPU actually at 100%, or is the client perceiving slowness from something else?
2
Check CRM for past suspensions
Repeat offenders often have a history — malware, abusive scripts, or chronically undersized plans.
3
SSH in and inspect running processes
Run top or htop. Sort by CPU%. Identify the offender.
4
Kill the offending process (if legit high load)
In top: press k → enter PID → signal 15. In htop: navigate to the process → press F9.
$ top # or the more readable version: $ htop # Look for processes with high CPU% values

Resolution options

🛠️ Optimise the app

Reduce plugins, fix code inefficiencies, enable caching, tune database queries. Client-side work — this is where #vps-comm1 sets expectations.

🔄 Remove CPU limit

Available once per week via hPanel. Buys the client time to fix the underlying issue.

🦠 Check for malware

High CPU is a classic malware signal. Always rule this out via hVPS Admin → Processes tab. (Full flow in chapter 4.)

⬆️ Upgrade plan

If the CPU is consistently maxed out even after optimisation, the plan is undersized. Recommend upgrade only after optimisation attempts.

⚠️ Special case — CPU Steal
CPU steal = your VPS is waiting for physical CPU because the host node is overloaded. This is NOT the client's fault.
  • Client's own processes look normal in top/htop
  • Server feels slow despite low reported CPU usage
  • Use predefine #vps-cpu-steal-node
  • Action: request VPS migration to a less-loaded node
References VPS CPU Limits (internal wiki) What is the CPU use limit for VPS
03 · Memory & storage

High RAM & disk usage

RAM and disk issues have distinct signals — but they're both handled from SSH with a few core commands.

🧠 High RAM — diagnostic

$ free -m

Key columns to explain to the client:

Column What it means
used Memory actively in use by running processes
buff/cache Kernel cache — normal, and released automatically when needed. Linux manages this. Not a problem.
available What's actually free for new processes. This is the number that matters.
📌 Teaching tip: hPanel shows used + buff/cache combined. Students (and clients) often panic at this — clarify that high cache is not a problem. Always check free -m to see the real picture.

💾 High disk space — diagnostic

Start with overall disk usage per filesystem:

$ df -h

Then find the largest directories:

$ du -sh /* 2>/dev/null | sort -rh | head -20

Check specifically for oversized log files (very common culprit):

$ du -sh /var/log/* | sort -rh | head -10

Resolution options — disk

🗑️ Delete unnecessary logs

hPanel → Settings → Delete unnecessary logs. Safe one-click cleanup.

🧹 Clean up large files

Via SSH or File Manager. Use the du output to find what's eating space.

📏 Expand partition after upgrade

If the client upgraded their plan but the new disk wasn't auto-allocated, the partition needs manual expansion (parted + resize2fs).

⬆️ Upgrade plan

When the disk is legitimately full and can't be cleaned enough.

References Detailed RAM Usage Delete VPS Logs Increase Partition Size
04 · Network & security

Bandwidth limits & malware

Two distinct issues that often present the same way: "my site is slow" or "my server is down." The diagnostics diverge fast.

📡 Bandwidth exceeded

What happens

  • Resets on the 1st of every month
  • When exceeded → speed throttled to 10 Mbps
  • Server stays online — just slow
  • Check: hPanel → Server Usage → Bandwidth graph

Resolution

  • Optimise content — compress images, enable caching
  • Monitor traffic peaks and identify heavy pages
  • Consider a CDN in front of the origin
  • Upgrade plan if bandwidth is regularly exceeded

🦠 Malware / cryptomining (important!)

High CPU doesn't always mean legitimate usage — it's frequently a malicious process, especially cryptomining. Always rule this out before recommending an upgrade.

🚩 Red flags in hVPS Admin → PROCESSES tab. If you see any of these process names, treat it as malware until proven otherwise:
xmrig cpuminer minerd cryptonight kaudit0 kauditd0 /.dhpcd ceremonyclient shaicoind
Category Process names What it means
Cryptomining xmrig, cpuminer, minerd, cryptonight Server hijacked to mine cryptocurrency. CPU pegged at 100%.
Hidden processes kaudit0, kauditd0, /.dhpcd Disguised as system processes — obvious red flag once spotted.
Blockchain abuse ceremonyclient, shaicoind Blockchain node abuse — resource-heavy, not the client's intent.

Steps when malware is suspected

1
Check hVPS Admin → Processes tab
Look for the known malicious process names above. Screenshot for record.
2
Use predefine #vps-cpu-malware
Notifies the client transparently and explains what's happening.
3
Guide client to run Monarx Malware Scanner in hPanel
Primary tool for scanning and cleanup — the client-facing path.
4
If no Monarx license: manual cleanup or restore from backup
Backup restore is often the fastest path back to a clean state.
5
After cleanup: recommend security hardening
Cloudflare protection, strong SSH keys/passwords, update all apps and plugins, close unused ports.
References Bandwidth Limits explained VPS Resource Limits Are Reached (internal wiki) React2Shell vulnerability (internal wiki)
05 · Mental model

The troubleshooting decision flow

Use this mental model for any VPS resource case. It's the same 5-step pattern every time — the branches change, but the flow doesn't.

Step 1

Check hPanel Server Usage — is any resource hitting the limit?

  • Yes → identify which resource (CPU / RAM / Disk / Bandwidth)
  • No → likely a software bottleneck. Use predefine #vps-slow-unmanaged
Step 2 — if CPU is high

Rule out malware first, then diagnose legit load

  • Check hVPS Admin → Processes tab for known malicious names
  • Then run top / htop for legit high-load processes
  • Also possible: CPU Steal → node migration (#vps-cpu-steal-node)
Step 3 — if RAM is high

Distinguish real usage from cache

  • Run free -m — check the available column, not used + cache
  • Identify top memory processes with top or htop
Step 4 — if Disk is full

Find the culprit, then clean or expand

  • df -h to see per-filesystem usage
  • du -sh to find the largest directories
  • Clear logs, clean files, or expand partition after plan upgrade
Step 5 — after fixing

Recommend the right long-term path

  • If consistently hitting limits → recommend upgrade
  • Always suggest optimisation before upgrade — respect the client's investment
The mental model in one line: See which resource is stressed → rule out malware if CPU → apply the resource-specific diagnostic → recommend optimisation, then upgrade if needed.
References VPS Resource Limits Are Reached (internal wiki) VPS CPU Limits (internal wiki) Slow VPS troubleshooting (internal wiki) How to check VPS resources usage Detailed RAM Usage Understanding CPU Steal Bandwidth Limits explained
06 · Practice

Practice cases

Read each scenario. Think through the approach before revealing the expected answer.

Case 1 · CPU

Client says VPS is slow. hPanel shows CPU at 100% for the past 6 hours. No malicious processes found.

Expected approach
SSH in → run top or htop → identify the high-CPU process → optimise or kill it (k + PID + signal 15 in top, or F9 in htop). If load is genuinely legitimate and recurring, suggest optimisation first, then plan upgrade. Client is responsible for optimising the application — set that expectation with #vps-comm1.
Case 2 · Malware

Client's VPS was auto-stopped. hVPS Admin → Processes tab shows xmrig running.

Expected approach
This is cryptomining malware. Follow the malware flow: use predefine #vps-cpu-malware → guide the client to run Monarx Malware Scanner in hPanel → if no license, manual cleanup or restore from backup → after cleanup, recommend security hardening (Cloudflare, strong passwords, SSH keys, update apps & plugins).
Case 3 · Software bottleneck

Client says website is slow but hPanel shows CPU, RAM, Disk all normal.

Expected approach
No resource limit is hit — this is an internal software bottleneck (slow queries, unoptimised code, buggy plugin, missing caching). Use predefine #vps-slow-unmanaged → guide the client to run top and use Kodee to analyse the application. VPS is self-managed — this is the client's optimisation work.
Case 4 · Partition

Client upgraded VPS plan but disk space didn't increase.

Expected approach
Plan upgrade doesn't always auto-allocate the new disk space. The partition needs to be expanded manually. Guide the client through the partition expansion process: parted to grow the partition, then resize2fs to grow the filesystem. Verify with df -h afterwards. Link them to the "Increase Partition Size" KB article.
07 · Check

Knowledge check

Pick an answer for each question — feedback appears immediately.

0 / 7 answered
Q1. A VPS sustains high CPU usage over time. What happens automatically?
Q2. What is CPU Steal and whose fault is it?
Q3. A client panics because hPanel shows high RAM. You SSH in and run free -m. What column tells you the actual truth?
Q4. A client exceeded their bandwidth limit for the month. What happens?
Q5. A client's VPS was auto-stopped. hVPS Admin → Processes shows xmrig running. What's the correct next action?
Q6. A client says their website is slow, but hPanel shows CPU, RAM, Disk all normal. What predefine and approach?
Q7. Client upgraded their VPS plan, but disk space still shows the same. Why?
08 · Reference

Key resources to share with students

Bookmark these — internal wikis for agent context, public KB articles for client-facing answers.

InternalVPS Resource Limits Are Reached InternalVPS CPU Limits InternalSlow VPS troubleshooting flow InternalReact2Shell vulnerability Public KBHow to check VPS resources usage Public KBWhat is the CPU use limit for VPS Public KBUnderstanding CPU Steal & its impact on VPS Public KBHow to check detailed RAM usage on your VPS Public KBWhat happens if your VPS bandwidth limits are exceeded Public KBHow to delete VPS logs Public KBHow to increase VPS partition size

Predefines quick reference

Predefine When to use
#vps-comm1 First reply — set expectation that VPS is self-managed
#vps-cpu-steal-node CPU Steal detected — request node migration
#vps-cpu-malware Cryptomining / malicious process detected in Processes tab
#vps-slow-unmanaged All resources normal but client reports slowness — internal software bottleneck
Remember: VPS is self-managed. Your job is to identify the resource issue, rule out malware, and point the client to the right optimisation or upgrade path. Set the expectation early with #vps-comm1 — it saves the whole conversation from going sideways.