loc bengaluru, ist | local --:-- srijanshukla18@gmail.com
[post]/you-a-junior-infra-techie/cpu-ram-disk

cpu ram disk

/ 7 min read· infra

Explaining CPU, RAM, and disk to juniors with a kitchen analogy: chef, counter, pantry. Covers iowait, steal time, throttling, overcommit, and IOPS vs bandwidth.

Quick disclaimer: I have found it a lil tough to translate my mental model about this stuff into words for juniors. I can explain it to them fine, but I am making up half the analogies on the fly when I do it. So I am writing one of them down properly this time.

When you build applications, you’ll hear people casually toss around CPU, RAM, Disk like everyone’s born knowing how they fit together. Here’s the picture I use: a restaurant kitchen.

The restaurant analogy

  • CPU = the chef. Does the actual cooking (computation). Fast, skilled, but limited hands. If he’s overloaded, dishes (tasks) wait. What you measure: speed (GHz) and how many chefs you have (cores).
  • RAM = the kitchen counter. Holds the ingredients the chef is actively using. Close by, quick to grab from, but space is limited. What you measure: size (GB). Too little counter space means constant running to the pantry, and that is slow.
  • Disk = the pantry/fridge. Long-term storage for all the ingredients. Huge, but slow compared to the counter. What you measure: capacity (GB/TB). Some pantries are faster (SSD) than others (HDD).

How they work together

  1. A customer places an order (your program runs). The chef (CPU) gets busy.
  2. The chef grabs ingredients from the counter (RAM). If they’re there already, fast. If not, the chef yells to the waiter: “Fetch from pantry!” (disk).
  3. If the pantry is slow (old hard drive), the chef spends his time waiting instead of cooking. This is why SSDs feel snappy.
  4. If the counter is too small (low RAM), ingredients keep getting shuffled back to the pantry. That’s “swapping”, and it’s painfully slow.

Toolbox view

  • CPU (compute power): crunching numbers. The more chefs and the faster their knives, the quicker the output.
  • RAM (working memory): active space. The bigger the counter, the more simultaneous dishes and ingredients the chef can juggle.
  • Disk (storage): the giant pantry. Holds everything, but too slow to cook directly from.

Performance principles

  • CPU bottleneck: the chef is overloaded. Adding more chefs (cores) or faster chefs (GHz) helps.
  • RAM bottleneck: the counter is too small. More RAM means fewer pantry runs.
  • Disk bottleneck: the pantry is slow. An SSD is a faster pantry than an HDD.

Key extras

  • Cache (L1/L2/L3) = mini spice racks right next to the chef. Super tiny, blazing fast.
  • Virtual memory = pretending pantry space (disk) is counter space (RAM). Works, but the chef hates it.
  • Throughput vs latency: CPU is how fast the chef can chop one onion (latency). RAM/disk is how many onions can be carried at once (throughput).

The one line to remember

CPU = chef, RAM = counter, disk = pantry. The chef only works well if the counter is big enough, the pantry is stocked and reasonably fast, and the chef isn’t overloaded.

Disk: IOPS vs bandwidth

(Chef’s pantry woes)

Picture your pantry. It’s not just about how big it is (storage capacity). It’s about how fast your sous-chefs can:

  • grab 1 ingredient quickly (IOPS)
  • carry a whole sack of potatoes at once (bandwidth)

IOPS = how many times per second you can open the pantry door. Small random grabs. Like yelling “Get me a clove of garlic!” 10,000 times. SSDs are speedy errand boys - they dart in and out with tiny stuff, no problem.

Bandwidth = how much total weight they can carry per trip. Huge loads. “Bring me 10kg of rice in one go.” If your pantry is fast and you batch requests, the pipeline flows.

Kitchen drama:

  • If you scream 100 tiny requests per second but your errand boy has two legs and no arms, you stall. That’s an IOPS cap.
  • If your errand boy is strong but the hallway is narrow, you hit bandwidth limits.
  • If you batch smartly (“get all the onions in one trip”), you get the most out of both.

CPU iowait = chef twiddling thumbs

Say the chef (CPU) is ready to cook, knife in hand.

“Where’s the garlic?” “Still coming from the pantry.” “Fine, I’ll wait.”

iowait = the time the chef spends doing nothing while waiting for the pantry boy.

  • Disk slow: iowait high.
  • The chef isn’t lazy, he’s blocked.

But if the network waiter is late (not disk), the chef isn’t even counted as iowait. He just sits there silently staring at the door, and the manager (the OS) logs it as “idle” or “waiting on someone else.”

So iowait is blameable delay. Network stalls are ghost delays - they don’t show up as iowait, but your food is still late.

CPU noisy neighbor = the other chef hogging the stove

Now imagine: you’re the main chef. You’ve prepped your dish. You reach for the stove, and BAM, some junior from another kitchen is already hogging it.

That’s noisy neighbor syndrome.

VM world = shared kitchen. That other chef? He belongs to another restaurant. But you’re both renting the same kitchen. When you want the stove, the landlord says “Wait, he’s using it right now.” That’s %steal: CPU time stolen from you.

Container world = shared utensils. You and another container share the knife set. Hit your CPU limits (ulimits/cgroups) and the kernel yanks the knife out of your hand mid-chop. That’s throttling.

Worst case: the chef gets part-time access to the stove, the pan, and the ladle, but the guests still expect full-course meals. You’ll miss your SLA. Guests walk out. Michelin star revoked.

RAM overcommit = the lying sous-chef

Alright, back to the kitchen counter (RAM).

You say, “I need space for 4 cutting boards.”

Your sous-chef says:

“Absolutely, Chef. There’s plenty of room. We’ll figure it out.”

They lie. They’re gambling you won’t use all 4 boards at once.

That’s overcommit. You think you have 4 counters. But when you reach for board #3, the sous-chef says:

“Uhhh… one sec, I need to move these dirty bowls to the pantry first.”

Boom. Swap kicks in. You just paid a massive latency tax because the sous-chef promised you virtual counter space instead of real wood.

Transparent Huge Pages? Those are giant chopping boards. If you only want to slice a lime, the chef still gets the giant board. Waste of space. And when there’s a space crunch, folding and unfolding those is slow.

Page cache = pre-chopped veggies. RAM stores stuff you used recently (file data) in the page cache, like mise en place - not active ingredients, but quick to grab again. Don’t wipe it unless you’re desperate. It’s smart.

Summary: kitchen operations breakdown

Metaphor ComponentReal ComponentWhen It Goes Wrong
ChefCPUHe’s idle, waiting for disk (iowait), or throttled (limits).
Knife/Stove/ToolsCPU CoresOther chefs hog them (steal time or CPU contention).
Kitchen CounterRAMToo small? You juggle. Overcommitted? OS lies, leads to swap.
PantryDiskSlow errand boy, or too many small trips = app stalls.
Walkway WidthDisk BandwidthBulk transfers get bottlenecked.
Trips to PantryDisk IOPSYou need a fast runner (SSD), or fewer small trips.
Sous-Chef’s Fake PromisesOvercommit MemoryYou crash during the rush. OOM killer slaps your station.
Giant Chopping BoardsTransparent Huge PagesGood for steakhouse, bad for sushi bar.

Next time someone tells you the box is slow, ask them which part of the kitchen is on fire.