High VPS CPU or RAM Usage: Diagnose the Cause

1. Record when and where the problem happens

Record the start time, time zone and affected function. Is every request slow, or only search, uploads or a background job? Check whether a deployment, backup or import began at the same time. These details make a high metric much easier to investigate.

date -Is
uptime
nproc

uptime includes load averages over one, five and fifteen minutes. Those values are not normalized by CPU count. Use nproc as an initial indication of available CPUs, then consider any separate process or container limits. Repeat the observations during normal operation and note intervening restarts.

2. Separate computation from waiting

vmstat 1 5

For many counters, the first vmstat report averages activity since boot. Later reports cover the selected interval; process and memory figures are instantaneous in either case. Compare several subsequent rows. A high load average can include blocked tasks even when CPUs have idle time.

An isolated wa reading does not identify a faulty disk, and one st spike does not establish a lasting host problem. Keep timestamps and repeated observations when asking the provider to investigate.

3. Check available memory and active swapping

free -h
grep -E '^(MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree):' /proc/meminfo

MemAvailable estimates how much memory new applications could use without swapping, accounting for some reclaimable memory. Low MemFree with reasonable MemAvailable and stable response times can be normal. Follow the trend during the incident rather than treating every cached byte as unavailable.

Used swap alone also does not prove current pressure. Look for sustained movement in the vmstat si and so fields while responses slow down. Together with low available RAM, that can support a memory-pressure diagnosis. Zero swap activity does not rule out a problem, especially when no swap is configured. Containers may also have lower limits than the VPS itself.

4. Look for OOM events and service limits

journalctl -k -b --since '-30min' --no-pager | grep -Ei 'out of memory|oom-kill|killed process'

This search also matches OOM warnings and handler invocations that do not prove a process was killed. Confirm an explicit OOM killed-process message, such as “Killed process”, and match its timestamp and PID to the affected service. An empty result does not rule out OOM: permissions, retention or the time window can hide events. Exit code 137 alone does not prove OOM.

A container or systemd service can reach its memory limit while the VPS has spare RAM. In cgroup v2, memory.max sets a limit; inspect the service group and its parent/slice groups because local memory.max=max does not override stricter ancestor limits. In memory.events, oom counts OOM situations; oom_kill counts processes killed by an OOM killer. Counter increases identify no PID: correlate them with the incident window and process logs. Adding VPS RAM does not automatically raise configured service limits.

5. Narrow the investigation to processes

ps -eo pid,comm,%cpu,%mem,rss --sort=-%cpu | head -n 12
ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -n 12

This uses process names instead of complete arguments, reducing unnecessary exposure of command-line credentials. Still review diagnostic output before sharing it. On Linux, RSS reports resident memory in KiB. Shared pages can appear in multiple processes, so summing all RSS values does not give an exact system total.

The ps CPU percentage is averaged over the process lifetime rather than just the last second. Treat the list as a starting point and compare it with repeated observations and scheduled jobs. A large database process is not automatically malfunctioning; it may hold useful working data.

6. Investigate avoidable work before upgrading

• Check whether backups, imports or batch jobs overlap unnecessarily.
• Investigate slow queries, missing appropriate indexes and repeated computation.
• Compare worker concurrency and memory needs with available resources.
• Use application logs to investigate unexpected traffic and error loops.

Change one understood factor and compare the same workload again. Fewer workers may reduce memory pressure while increasing queue delays, so measure both. Clearing caches indiscriminately or stopping unfamiliar processes is not a diagnosis. Memory that grows after every similar request may need investigation in the application.

7. Make the resource decision measurable

More RAM is plausible when the necessary working set still creates sustained pressure after reasonable configuration changes. More vCPU can help parallel computation. Neither automatically fixes a serial bottleneck, slow external API or fixed container limit. State the improvement you expect before selecting another plan.

• Keep the incident window and affected application function.
• Record repeated CPU, memory and I/O observations.
• List examined jobs, configuration changes and service limits.
• Define success through response times, queue delays or memory-related failures.

After any change, verify application behavior as well as resource graphs. A lower utilization figure alone does not confirm that requests are completing correctly.