A busy Linux CPU does not explain every slow page

A CPU chart climbs just as a page takes longer to arrive. The timing is suggestive, but the chart has not yet explained the wait.

In this lab, you will know where the extra CPU work came from because you will start it yourself. Then you can watch it end and see whether a small web request noticed the busy interval at all. Use two terminals inside the disposable Ubuntu VM, not a shared production machine. The workload is bounded to ten seconds.

See the quiet guest before making it busy

Take a reading before the experiment. It gives the later busy and quiet periods something concrete to compare with:

uptime
free -h
vmstat 1 5
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head

uptime reports load averages. These reflect work running, waiting to run or in uninterruptible sleep, including some storage waits. They are not percentages of CPU use. A high load number and a CPU percentage describe different things.

free distinguishes available memory from unused memory. Cached data can occupy memory that is not strictly free while the system still has memory available for work. The small-looking free column is not, on its own, a shortage diagnosis.

Read the first vmstat row separately from the rest: it summarizes activity since boot. Later rows describe recent intervals. Those later readings are the ones that can follow a short burst of work closely enough for this experiment.

Ten seconds of work with a known source

In the first terminal, start this bounded loop:

timeout 10s python3 -c 'while True: pass'

While it runs, repeat vmstat 1 5 and the process listing in the second terminal. Look for Python using roughly one logical CPU, subject to scheduling and quotas. When the limit expires, timeout normally exits with status 124. Here that is the intended stopping point, not a surprise failure of the exercise.

Watch which readings settle afterward. The loop deliberately asks for CPU work; it does not create a disk workload. If you want to explain a storage delay, you will need observations of storage activity rather than borrow a conclusion from this CPU change.

On a guest with two logical CPUs, Python may appear near 100% in the process listing while the overall machine still has substantial idle capacity. One process can occupy one CPU while another CPU has room. Check the unit behind each percentage before concluding that the tools disagree.

Time matters as well. A process percentage can describe the process’s lifetime, whereas the later vmstat rows describe short intervals. Compare readings from the same ten seconds; a brief burst may stand out in one view and be averaged away in another.

Other shortages, without manufacturing them

The following observations are hypothetical leads for other investigations. They are not results from our CPU loop, and you do not need to exhaust the guest to consider them.

Observation	Useful next check	Conclusion still missing
High runnable queue and busy CPUs	Identify CPU-heavy processes and quotas.	Which work produced the demand?
Swap activity with low available memory	Inspect process growth and cgroup limits.	Whether a leak or intended workload caused it.
Long I/O waits and delayed writes	Check device latency and application I/O.	Whether storage or the access pattern is responsible.
Filesystem at full capacity	Map the affected path with findmnt and df.	Which safe cleanup or capacity action applies.

In the table, cgroups are groups of processes with resource controls, such as assigned limits. A container can hit its own limit even while the host has room left. Likewise, memory growth could come from intended work or a leak, and a busy interval may finish by itself. The measurement points toward a question; the workload and its limits supply the explanation.

Did the page actually wait?

If the practice HTTP service is running, request its page before, during and after the CPU loop:

curl -sS -o /dev/null -w 'HTTP %{http_code}; total %{time_total}s\n' http://127.0.0.1:8080/

The output includes the HTTP status and total request time. You may observe little or no slowdown for this small local request. Keep that result beside the busy CPU reading. The machine did more work, but the request may still have received the resources it needed.

Record the process, resource and time interval next to the measured request, plus another explanation worth checking. Keep the workload bounded. Those details let another person connect the observations instead of trying to infer the experiment from a chart alone.

A fast response is useful information. Serving a small static file may need little CPU; the scheduler may give it enough time, or another logical CPU may be available. Learning about a larger application would require its representative work. Enlarging this loop merely to force a slowdown would change the question, not explain the original page.

The measurements and the stopping point

procps-ng maintains vmstat, free and ps. The GNU timeout manual describes time limits and exit statuses. The workload and comparison table are synthetic exercises.