It’s easy to guess wrong about which resource needs upgrading — adding RAM to a server that’s actually disk-I/O-bound, for instance, won’t move the needle. Here’s how to diagnose it properly first.
Checking RAM pressure
Run free -h on Linux and look at the “available” column, not just “free” (modern Linux uses spare RAM for disk caching, which shows as “used” but is actually reclaimable). Consistently low “available” memory alongside active swap usage (swapon --show) is a genuine sign you need more RAM.
Checking storage bottlenecks
Use iostat -x 1 (from the sysstat package) and watch the %util column — sustained values near 100% indicate your storage is the bottleneck, regardless of how much free space remains. This is a different problem from running low on disk space (check with df -h) and usually points to needing faster storage (NVMe over SATA SSD) rather than just more of it.
Checking bandwidth/network limits
Monitor actual throughput with a tool like vnstat or your provider’s network graphs. If you’re regularly saturating your allocated port speed (commonly 1 Gbps) during peak hours, that’s a genuine bandwidth ceiling — distinct from a CPU or storage issue, and one that only an upgraded network allocation fixes.
Checking CPU load
top or htop shows real-time CPU usage per core; sustained high load averages (viewed via uptime) relative to your core count over time indicates genuine CPU pressure rather than a brief spike.
Upgrading based on evidence, not guesswork
Once you’ve identified the actual constrained resource from the checks above, request that specific upgrade rather than a general “bigger server” — this keeps costs proportional to the real bottleneck. Re-run the same checks a week or two after any upgrade to confirm it resolved the pressure rather than simply shifting it elsewhere (e.g. more RAM revealing that storage was the next limit).