Phase 2 · Free

Lab: Phase 2, Know Your Hardware

A hardware inventory you could hand to another tech, plus proof you can find a bottleneck.

45 minPhase 2: Know Your HardwareFree

Cost: $0. Tools: your Phase 1 Ubuntu VMA software-based emulation of a complete computer that runs its own operating system and applications, isolated from the host hardware. Read more → (or bare metal), apt packages htop, smartmontools, stress-ng, lshw (all free).

Goal

A hardware inventory you could hand to another tech, plus proof you can find a bottleneckThe single component or resource that limits a system's overall performance, so improving anything else makes little difference until it is fixed. Read more →.

Steps

  1. mkdir -p ~/course-notes/phase-2-hardware && cd ~/course-notes/phase-2-hardware
  2. Run and save each of these into hardware-inventory.md, one section per part: lscpu, free -h, lsblk -o NAME,SIZE,TYPE,TRAN,MODEL, df -h, lspci -k, lsusb, ip -br link, sudo lshw -short. Example: echo '## CPU' >> hardware-inventory.md && lscpu >> hardware-inventory.md
  3. Under each section, write two lines in your own words: what the part is, and the key number (cores, GB, disk type, driver).
  4. Write a VM vs host table: what the guest reports versus what your real computer has (look up the host in Windows System Information, macOS About This Mac, or the maker’s spec page). Explain each difference.
  5. Bottleneck drill: run stress-ng --cpu 2 --timeout 30s with vmstat 2 10 in a second terminalThe window or screen where you type text commands and read their output, connected to a shell that runs those commands. Read more →. Save the vmstat output and circle (in text) the columns that changed.
  6. Bare metal only: sudo smartctl -H on your disk.

Worked troubleshooting: “the VM got slow”

Symptom. Everything in the VM feels slow. Typing lags.

Hypothesis. One part is at its limit. CPU is the first guess, because lag while typing usually means nothing is free to respond.

Test. Look at load, the CPU columns, and the top process. Captured on the course VM during stress-ng --cpu 2:

vmstat 2 3
ps -eo pid,comm,%cpu --sort=-%cpu | head -4
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 2  0      0 1739136  28180 888376    0    0     0     0 2288  847 99  1  0  0  0  0
    PID COMMAND         %CPU
   3248 stress-ng-cpu   98.7
   3249 stress-ng-cpu   98.7

Read it: us at 99 and id at 0 means the CPU has no idle time. si, so and wa at 0 rule out memory and disk. ps names the process.

Fix. Stop or limit that process. Here it ends on its own after the timeout. In real life you would find out why it is busy before killing it.

Why it worked. You ruled parts in and out with numbers instead of guessing, so the fix went to the part that was actually full. The first vmstat line is an average since boot; read the lines after it. Your numbers will differ.

Proof

  • hardware-inventory.md
  • bottleneck-test.md with vmstat output and your reading of it.

Done when

Someone who has never seen your machine could tell, from your files alone, its CPU, RAMRandom Access Memory: the fast, temporary working memory that holds the programs and data a computer is using right now, cleared when power is lost. Read more →, disk type, network driver, whether it is virtual, and what slowed down in your stress test.