Asciiroot Systems

Linux troubleshooting guide

Linux high CPU or load: distinguish the symptoms

High CPU utilization and high load average are related but different symptoms. Identify the affected workload and compare CPU and waiting-task evidence before changing limits or stopping processes.

Before you begin: These examples use Linux uptime and procps tools. Container limits, CPU counts and metrics vary by runtime and version. These examples are not executed or verified against your system. Obtain authorization, protect sensitive output and involve the responsible owner.

Clarify the incident

Collect the relevant scope and timeline before choosing an action:

  • Is CPU utilization high, is load average high, or are both high on the affected host?
  • Which process, container or workload is affected, and how does usage vary over time?
  • Did traffic, deployment, scheduled work or resource limits change before the event?

Possible explanations

These are alternatives to investigate, not confirmed causes:

  • An application workload, traffic increase or CPU limit may cause saturation; compare the relevant metrics.
  • High load can also include tasks waiting in uninterruptible states, so it is not by itself proof of high CPU usage.

Read-only checks

Replace example names and paths only after confirming the applicable platform, permissions and change policy. Command output can contain sensitive data.

Linux: load overview

Compare load with CPU count and actual CPU and I/O metrics. If load is high without high CPU utilization, investigate runnable and blocked tasks; load is not a CPU percentage.

uptime

Linux with procps: process snapshot

Compare the listed processes with time-series and container metrics before deciding what to investigate. This snapshot is not proof of root cause; process details may be sensitive.

ps -eo pid,comm,pcpu,pmem --sort=-pcpu | head -n 10

Interpret the evidence

High CPU and high load

Compare process and container activity with traffic, scheduled work and CPU limits over the relevant period. A single process snapshot is not a time series or proof of the cause.

High load but CPUs mostly idle

Load can include tasks waiting in uninterruptible states as well as runnable tasks. Investigate storage or other waiting dependencies rather than assuming CPU saturation.

Host and container views differ

Compare the affected workload with its own CPU quota and the host baseline. A healthy host average can hide a constrained container.

Plan recovery and verification

  1. Confirm impact: Identify affected services, users, time range and the responsible owner.
  2. Gather measurements: Compare CPU, load, I/O wait, process trends, container limits and recent workload changes.
  3. Prepare rollback: Record the baseline and recovery plan before altering limits, capacity or workloads.
  4. Choose a controlled mitigation: Agree with the owner on the smallest safe change; do not terminate unknown processes.
  5. Verify and monitor: Check user impact and resource trends after the approved action and watch for recurrence.

Watch for recurrence: After an approved mitigation, compare user impact and resource trends with the baseline. If the symptom returns, capture the same workload, limit and dependency evidence before changing capacity again.

Documentation pointers

Check the documentation for your product and installed version. These links are references, not live verification.

Explore a safe demonstration

The scenario lab illustrates a fixed example. It does not reproduce this incident or verify a production fix, and it never executes your commands.

Open the related scenario lab

Related Linux guides