How to Diagnose High CPU Usage on a Linux VPS

High CPU usage can mean a server is doing exactly the work you bought it to do. It becomes a problem when requests slow down, jobs miss deadlines, or the activity has no legitimate explanation. Begin with the affected service and the time the symptom started. That context makes a process list much more useful than a screenshot of a busy CPU gauge.

Establish whether the symptom is current

Check the public service from a separate machine and compare current response times with the baseline. Record whether all requests are slow or only an expensive route. Then collect a short series of guest measurements. vmstat 1 10 provides interval observations after its initial report; its CPU fields distinguish user, system, idle, I/O-wait, and stolen time. Consult the vmstat manual for the definitions used by your installed version.

Identify the process without exposing secrets

Use a process viewer to find the main consumers and record their names, process IDs, and service ownership. Avoid pasting complete command lines or environment dumps into a public issue, because applications sometimes place credentials there. Inspect whether one worker is busy or many are active. A single worker looping on an error suggests a different investigation from every worker processing a traffic spike. Check how long the process has existed and whether the service manager is repeatedly replacing it.

Connect the activity to a recent event

Build a short timeline from deployments, scheduled tasks, traffic changes, and application logs. For example, a search reindex beginning at 14:00 may explain CPU activity that appears at 14:01, but the coincidence alone is not proof. Examine its progress and pause or reduce the task through its documented controls if doing so is safe. If latency improves while ordinary request volume remains similar, you have stronger evidence that the batch work competed with customer traffic.

Choose the smallest useful experiment

Change one factor at a time: background concurrency, an expensive request path, a recent release, or a cache setting whose behavior you understand. Define the expected result first. If you halve a report worker pool, you might expect lower CPU contention and a longer report completion time. Verify both. Avoid unbounded stress tools during an incident; they add demand to the resource you are investigating. Repeatedly force-killing a process can also discard evidence and interrupt writes without fixing its restart trigger.

Verify the recovery and prevent repetition

After mitigation, check response time, error rate, queue depth, and the completion of delayed work. A lower CPU chart is not enough if requests now wait in an application queue. Document the observed cause, the change made, and the condition that would justify more capacity. If unexplained activity points to a compromised guest, isolate the affected service and follow your incident procedure rather than trusting a process-name change or a reboot to remove the problem.

Keep a sanitized diagnostic record with UTC timestamps when contacting support through LayerOne's documented support paths. If sustained legitimate demand is the constraint, compare resources on the pricing page after checking how effectively your application uses additional CPUs.