Diagnose performance problems, disk errors, and resource limits on your vps.direct VPS.

Hardware Issues

On a virtual server, "hardware issues" usually mean resource limits, disk problems, or a noisy neighbour — not a physical part you can touch. This page helps you tell them apart and fix what's fixable.

If you suspect a genuine host hardware failure (your VPS and only your VPS keeps crashing with no software cause), open a support ticket — support can migrate you to a healthy host.

Slow performance

Start by finding what's saturated. Install and run htop:

sudo apt install htop -y
htop

Symptom	Likely cause	Fix
CPU at 100%, one core pinned	Single-threaded app (e.g. Minecraft tick loop)	Use a Premium (high-clock) plan or optimise the app
CPU at 100%, all cores	Genuinely CPU-bound workload	Upgrade to more vCPU
RAM full, swap in use	Not enough memory	Upgrade RAM or reduce memory allocation
High `wa` (I/O wait) %	Disk-bound	Check disk below; may need more IOPS
Load high, CPU low	Waiting on disk or network	Investigate disk/network, not CPU

Minecraft and similar game servers are single-threaded for the main tick loop — a higher clock speed (Premium Ryzen) helps more than more cores. See Hardware Information.

Disk problems

Check disk health and usage

df -h                      # free space
iostat -xz 1               # IOPS and latency (install: sudo apt install sysstat)
smartctl -a /dev/sda       # SMART health (install: sudo apt install smartmontools)

Common disk issues

Full disk — df -h shows 100%. Clear logs, caches, or old backups. A full disk can stop services and prevent logins.
High I/O wait — another service is hammering the disk, or your workload exceeds the disk's IOPS. Move a database to more RAM, batch writes, or upgrade.
Filesystem errors — after a hard crash or force-stop, the filesystem may need a check. Boot into rescue mode and run fsck.

A fsck on the root filesystem must run from rescue mode or the web console at boot — never on a mounted live root partition.

Out of memory (OOM)

When the OS runs out of RAM, the OOM killer terminates processes — often your main service. Check the logs:

dmesg -T | grep -i "out of memory"
dmesg -T | grep -i "oom-killer"
journalctl -k | grep -i oom

Fixes:

Reduce the memory allocation of your app (e.g. lower -Xmx for Java)
Add swap as a temporary buffer (not a substitute for RAM)
Upgrade to a plan with more RAM

Check your resource allocation

Confirm the VPS actually has the resources you're paying for:

nproc            # number of vCPUs
free -h          # RAM and swap
df -h            # disk
lscpu            # CPU model and details

If these show less than your plan, verify you're looking at the right service in the Client Area, then open a ticket if the allocation is wrong.

The VPS keeps crashing or rebooting

Check the logs first — most crashes are software, not hardware:

journalctl -b -1 -p err      # errors from the previous boot
last -x | head               # reboot history

Rule out OOM — see above; the OOM killer will silently kill your main process.
Rule out a bad config change — kernel parameters, network config, or a failed update can cause boot loops. Use the web console to watch the boot and fix the cause.
Suspect the host — only if crashes are random, happen across reboots, and have no log explanation. Open a ticket with the boot logs.

Network looks like a hardware issue

Sometimes what feels like a hardware problem is actually the network. If your server "freezes" but stays online, see Network Problems — high latency or packet loss can mimic a hung server.

When to contact support

Open a ticket from the Client Area if:

Your VPS repeatedly crashes or reboots with no software cause in the logs
Allocated resources (nproc, free) don't match your plan
You see persistent high I/O wait that doesn't match your workload
You suspect a host hardware problem affecting your VPS

Include: Service ID, the command output (htop, dmesg, journalctl), and a description of when the problem started.

Hardware Issues

On this page