Record the symptom and time interval, including application latency and errors. Identify whether the system is a VM with host scheduling constraints. Use read-only observations before changing worker counts or restarting services.

1. Inspect uptime/load averages and the available CPU count. Compare sustained load with the workload's normal baseline instead of applying one universal threshold.
2. Use top or a short vmstat sample to distinguish CPU execution, idle time, I/O waits and runnable/blocked tasks. In a VM, inspect steal time as a possible host scheduling clue.
3. Identify the processes consuming CPU and determine whether the work is expected, such as compression, indexing, backups or application requests.
4. If CPU is not saturated, inspect storage latency, blocked tasks and memory pressure. A queue of disk-bound work can raise load even while processors are partly idle.
5. Make one evidence-based adjustment: reschedule background work, optimize the identified application path, reduce harmful concurrency or add suitable capacity. Keep the original baseline for comparison.

On the affected Linux server, run this short sample from an authorised SSH session during the slowdown. These commands read the system state. The processor count provides context for the load average; it does not establish the CPU allowance of a restricted hosting account.

uptime
nproc
vmstat 1 5

Read the result: Compare the one-minute load with the available processors, then examine the later vmstat samples. A sustained runnable queue with little idle CPU points toward CPU demand. Blocked tasks and I/O wait suggest a storage investigation. Treat the first vmstat line as an average since boot, not a fresh one-second measurement.

Record the sample time and affected application. One brief spike cannot justify a server upgrade or reboot. Compare another sample during normal operation and inspect the busiest process before choosing a remedy.

No. Available CPUs, task states, workload expectations and latency matter. The same value can be normal on one system and severe contention on another.

Compare response times and error rates under similar demand after the change. Confirm reduced load corresponds to useful service improvement rather than simply stopped customer work. Observe the next scheduled batch or backup cycle.

If the cause is intermittent, collect bounded monitoring samples around the event and correlate host and guest timestamps. Do not kill unfamiliar processes or raise process priority across the server to make the load display fall. A high load number alone is not sufficient evidence for a reboot.

• Diagnosing memory pressure before adding Linux swap
• Investigating an out-of-memory process kill on Linux
• Finding which process listens on a Linux network port
• Diagnosing a Linux server with no free inodes

• Debian manual: Uptime.1.en
• Debian manual: Vmstat.8.en
• Linux kernel: Psi