Understanding Linux Load Average on a VPS

Linux load average is useful precisely because it describes more than CPU usage. That also makes it easy to misread. A server with a high load value might be doing useful computation, waiting on storage, or experiencing a short burst that has already ended. The number should guide your next observation, not decide the remedy by itself.

Know what the three numbers represent

uptime reports averages over one, five, and fifteen minutes. On Linux, load includes runnable tasks and tasks in uninterruptible sleep, commonly associated with I/O waits. The values are not normalized by CPU count. These definitions are documented in the procps uptime manual. Record the server's available CPU count alongside the numbers so comparisons between machines make sense. Treat a reading taken just after startup differently from one collected during steady traffic.

Read the direction before the magnitude

Consider an illustrative reading of 6.0, 2.0, and 0.8. Recent demand is higher than the longer-term baseline, so a new burst or recent change deserves attention. A reading of 0.8, 2.0, and 6.0 suggests the opposite direction: earlier contention may be subsiding. These are clues, not exact histories. Check graphs and timestamps to establish when the change started. A deployment, backup, or scheduled report beginning at the same time is a useful hypothesis to test.

Pair load with CPU and blocked tasks

Observe vmstat 1 5 and an interactive process view. If runnable work stays high while CPUs remain busy, investigate which processes are using execution time. If many tasks are blocked and CPU execution is modest, storage or another kernel wait may matter more. The first vmstat report can summarize activity since boot, so use later interval samples for the current condition. Look for repeated patterns over several samples rather than treating a single line as a complete diagnosis.

Use an application example to choose the next step

Suppose a two-vCPU web server becomes slow during a nightly archive. The load rises, archive compression consumes CPU, and ordinary HTTP requests wait behind it. Reducing archive concurrency or moving the schedule is a reasonable experiment. In a different incident, the same load value appears while database writes stall and application processes wait. That case calls for storage and database investigation. Buying additional CPUs based only on the shared load value would skip the information that distinguishes the two problems.

Turn the observation into a useful record

Write down the load values, CPU count, affected customer action, duration, leading processes, and any concurrent maintenance. Capture enough before restarting a service to compare the result afterward. If customer latency returns to normal but the fifteen-minute average remains elevated, allow time for that average to reflect recovery. For alerting, combine load with sustained symptoms or a known capacity threshold. A high number without user impact can still deserve investigation, but it does not automatically justify an urgent page.

The LayerOne help center covers service controls if you need to inspect the VPS from the portal. Keep guest measurements alongside portal observations, and use the plan selection guide when evidence points to a recurring capacity constraint.