Learn › Mental Models › Everything is a Queue
uptime - a hands-on Linux lab on a real virtual machine.
Hands-on instantiation of the queue model on a real machine: measure capacity with nproc, flood the CPU with 8 hogs, watch the 1-minute load climb past the core count, feel the queueing delay in your own keystrokes, then drain it.
Work order 4471 just landed on your desk: api-worker-07 feels slow, but every dashboard is green. You know from the Everything is a Queue lesson exactly what that smells like: utilization is not saturation, and somewhere there is a line the dashboards do not graph.
This machine is yours. You are going to measure its capacity, overload it on purpose, watch a real run queue grow past the core count, and then drain it back to healthy. Everything you saw on the chart happens here, for real, with your own hands on the controls.
Your progress is tracked automatically. Just type commands naturally, and completed tasks light up on the left as the system detects them. There is nothing to submit.
Press Tab while typing a path or command and the terminal completes it for you. Build the habit now: every Linux engineer relies on it.
A queue has three numbers: the arrival rate (how fast work shows up), the service rate (how fast the servers finish it), and the queue depth (how many jobs wait in line). For the CPU's run queue, the servers are your cores, and Linux reports the line length as the load average.
The rule you proved on the chart: when arrivals exceed capacity, the line does not grow politely. It grows without bound, and the machine feels broken while every core reads merely busy.
Find out how many CPU cores this machine has.
The queue means nothing until you know how many servers work it. One command answers it:
nprocYou will see a single number. That is your service capacity: the load average reading that means every core is exactly busy with nobody waiting.
Read the load average while the machine is idle.
uptimeYou will see something like:
23:16:57 up 0 min, 0 user, load average: 0.22, 0.05, 0.02Your numbers will differ; the shape will not. The three values are the run queue depth averaged over 1, 5, and 15 minutes. Near zero means the line is empty: every process that wants a core gets one instantly. Write your idle 1-minute number down. You are about to destroy it.
cat /proc/loadavg shows the same numbers raw, straight from the kernel's bookkeeping. Either command counts for this task.
Start at least 8 CPU hogs: processes that demand a core forever.
The command yes prints the letter y in an infinite loop as fast as one core allows. Sent to /dev/null (the kernel's trash chute) with an ampersand to run it in the background, it becomes a perfect arrival that never leaves:
yes > /dev/null &Run it eight times. Eight arrivals, four servers: demand is now double capacity, exactly the over-100-percent territory from the second chart in the lesson.
Pressing the Up arrow recalls your previous command. Up, Enter, Up, Enter is the fast way to launch eight of them.
This machine is disposable and yours: flooding it is the assignment. On a production box this same experiment is an outage. The entire point of doing it here is that you will never need to do it there.
Push the 1-minute load average past your core count.
Run uptime again. Then wait half a minute and run it again. The 1-minute number is climbing toward 8, and the task completes the moment it passes your core count.
uptimeNotice the lag: you started 8 hogs seconds ago, but the 1-minute number climbs gradually. Averages smooth on purpose. This is why the lesson told you to read all three numbers: a high 1-minute with a low 15-minute says NEW problem, the reverse says an old one is fading.
While you wait, feel the saturation directly: type any command and notice the terminal itself hesitating. Your shell is now standing in the same line as the hogs. That hesitation is queueing delay, experienced from inside the queue.
Kill every hog and bring the machine back to healthy.
pkill yesOne command, all eight gone. Run uptime a few more times and watch the recovery: the 1-minute number falls quickly, the 15-minute number remembers the incident longest. The queue drains the moment arrivals stop, exactly as the backlog chart promised when you dragged the slider back under capacity.
Next instantiation, same model, different subsystem: the socket accept queue, where connections stand in a line nobody is draining. The shape will already be familiar. That is the entire trick.
Practice Lab: Read the Run Queue in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.