Demo: watching RAM and CPU while opening apps
On This Lesson 11 topics
Lesson Overview
So far this module has given you words and pictures: input and output, CPU, RAM, storage, bits, the operating system, processes. In this lesson you stop reading and start measuring. You will watch your own computer's RAM and CPU while you open and close applications, write down what you see, and explain each change with the ideas you have learned.
This lesson is a guided demonstration, and it is also the preparation for the module lab, Know your machine. Follow the steps on your own computer. The numbers will be different on every machine, so this lesson gives you no sample values to copy. What it gives you is a method, a recording table, and a way to reason about what you see.
Why this matters: engineers do exactly this on servers every day. They take a reading, change something, take another reading, and explain the difference. Doing it once on your own machine builds the habit.
You need a computer running Windows, macOS, or Linux, about 20 to 30 minutes, and a notebook or a text file to record readings. Lesson 5 explained the tools. Nothing in this lesson changes your system.
Learning Objectives
By the end of this lesson you will be able to:
- Find your computer's CPU model, total RAM, and storage type and capacity.
- Record a baseline of RAM in use and CPU use while the machine is idle.
- Open an application, measure the change in RAM and CPU, and close it and measure again.
- Explain the changes using CPU, RAM, storage, process, and the operating system.
- Identify the five processes using the most memory and record their names, PIDs, and memory.
- Describe why measurements vary, and how to make a fair comparison.
Written Explanation
The method: baseline, change, measure, explain
Every careful measurement follows four steps:
- Baseline. Record the state before you do anything.
- Change. Do one thing.
- Measure. Record the state again.
- Explain. Say why the numbers moved, using the concepts you know.
Change one thing at a time. If you open three apps at once, you will not know which caused which change.
Part 1: Know your machine
Record these four facts. Menus differ by version, so use search in your system settings if you cannot find them.
| Fact | Windows | macOS | Linux |
|---|---|---|---|
| CPU model and number of cores | Task Manager > Performance > CPU | Apple menu > About This Mac | lscpu in a terminal |
| Total RAM | Task Manager > Performance > Memory | Apple menu > About This Mac | free -h |
| Storage type and capacity | Task Manager > Performance > Disk, or Settings > System > Storage | Apple menu > About This Mac > Storage, or System Information | lsblk or df -h |
| Operating system and version | Settings > System > About | Apple menu > About This Mac | cat /etc/os-release |
Two cautions. First, RAM and storage are different numbers. A machine may have 16 GB of RAM and 512 GB of storage (Lesson 2). Make sure you write down both and label them. Second, to learn whether your storage is an SSD or an HDD, look for words such as "SSD", "solid state", or "NVMe" in the disk information. If the tool does not say, search for your computer's model name.
Part 2: The baseline
Close the apps you can, so the machine is as quiet as you can make it, and wait about a minute. Then record:
- RAM in use. Windows: Task Manager > Performance > Memory ("In use"). macOS: Activity Monitor > Memory tab ("Memory Used"). Linux: the "used" column of
free -h. - CPU use. Windows: Task Manager > Performance > CPU (percent utilisation). macOS: Activity Monitor > CPU tab (the idle and user percentages at the bottom). Linux: the CPU line at the top of
top.
An idle machine is rarely at zero. The operating system and background processes always use some CPU and RAM (Lesson 5).
Also record the five processes using the most memory. Sort the process list by memory and write down name, PID, and memory for each. These tools are the ones from Lesson 5: Task Manager's Processes and Details tabs, Activity Monitor's Memory tab, or top and ps on Linux.
Part 3: Open one large application
Choose one app that is large enough to notice, for example a web browser with a few tabs, a video editor, a large game, or an office suite with a big file. Open it and wait until it has finished loading, which may take several seconds. Then record the same two readings again: RAM in use and CPU use.
What to look for:
- CPU often jumps while the app starts, because the CPU is running the app's start-up instructions, and then falls back once the app is idle. If you read the CPU a moment after opening, you may catch the peak or the calm, so say which you recorded.
- RAM in use usually rises, because the operating system copied the program (and any file you opened) from storage into RAM (Lesson 2) and the app asked for working memory (Lesson 4).
Find the app's processes in the list. How many are there? What are their PIDs and memory? (Lesson 5: one application may be several processes.)
Part 4: Close it and measure again
Close the application normally. Wait a few seconds and record RAM in use and CPU use once more.
Usually RAM in use falls, because the process ended and the operating system took back its memory (Lesson 4). It may not fall all the way back to the baseline. There are normal reasons:
- The operating system may keep recently used data in otherwise free RAM, in case you need it again soon, and release it automatically if another program needs the space.
- Other background processes may have started or stopped in the meantime.
- Some applications leave helper processes running after you close the window.
So a small gap between the baseline and the final reading is not a sign of a fault.
Making the measurement fair
Real measurements are noisy. These habits help:
- Wait after each change so the numbers settle.
- Change one thing between readings.
- Repeat the measurement once or twice. If two readings differ a lot, you are probably seeing background activity.
- Use one tool for all readings (Lesson 5: different tools measure memory differently).
- Write down what you did, not only the numbers.
Turning numbers into an explanation
A good explanation connects the number to a concept. Compare:
- Weak: "RAM went from 6.1 to 7.4 GB."
- Better: "RAM in use rose after I opened the application, because the operating system loaded the program from storage into RAM and the new process asked for working memory."
Notice that the better version names the process, the operating system, storage, and RAM. Those are the words the lab asks you to use.
Examples
These examples show the shape of a good record. The figures are placeholders: replace them with your own readings.
Example 1: the recording table (simple)
| Step | RAM in use | CPU use | Notes |
|---|---|---|---|
| 1. Machine facts | Total RAM: ___ | CPU model, cores: ___ | Storage: ___ (type, capacity) |
| 2. Baseline (idle) | ___ | ___ | Which apps were open: ___ |
| 3. App open and loaded | ___ | ___ | App: ___, processes: ___ |
| 4. App closed | ___ | ___ | Did RAM return to the baseline? |
Example 2: a good observation sentence (practical)
"After opening the editor, the RAM in use went up and the CPU rose briefly and then fell. This is because the operating system copied the editor from storage into RAM, the CPU ran its start-up instructions, and once the editor was waiting for me the CPU had little left to do."
This sentence uses RAM, storage, CPU, and the operating system, and it explains why, not just what.
Example 3: an unexpected result (realistic)
Suppose RAM in use did not drop to the baseline after you closed the app. A careful student does not write "the app has a bug". They check the process list for leftover processes from that app. If there are none, they note that the operating system may be keeping recently used data in free RAM, repeat the reading a minute later, and report what they found. An honest "I am not sure, here is what I checked" is a good answer.
Backend Insight
On a server, the same method is how engineers investigate problems.
- Baseline first. Teams record normal CPU and memory so they can spot abnormal values. A reading means nothing without something to compare it to.
- Change, measure, explain. After a new release, they compare memory and CPU with those before, to see what it cost.
- One variable at a time. The same discipline that makes your laptop measurement fair makes a performance test trustworthy.
- Watch the process. The process list you used is the first place to look when a service is slow.
On a server there is often no graphical tool, so the same readings come from commands such as top or free -h. Later modules add monitoring tools that record these numbers over time.
Common Mistakes
Mistake 1: Skipping the baseline
Without it, you cannot say whether a number is high or low, or what your action changed. Always take the "before" reading.
Mistake 2: Changing several things at once
Opening three apps and watching RAM rise tells you nothing about which one used what. Change one thing, measure, then change the next.
Mistake 3: Reading the numbers too early
Right after you open an app, it may still be loading. Wait until it settles, and say whether you recorded a peak or a settled value.
Mistake 4: Mixing up RAM and storage in your table
Your machine may have 16 GB of RAM and 512 GB of storage. A record that says "memory: 512 GB" is mixing the two (Lesson 2).
Mistake 5: Concluding there is a fault when the numbers are not exact
Small differences and RAM that does not return exactly to the baseline are normal. Do not invent a cause. Check, repeat, and report what you saw.
Exercises
Try each exercise yourself. These are hands-on, so there are no fixed answers, but there are answers to check against.
Level A: Foundation
A1. Record your CPU model, number of cores, total RAM, and storage type and capacity. Label each one.
Show solution A1
A1. Your own values. Check that you did not mix RAM with storage, and that you gave the storage type (SSD or HDD) or noted that you could not find it.
A2. Take a baseline: RAM in use and CPU use with the machine as idle as you can make it. Which apps were open?
Show solution A2
A2. Your own values. A baseline has some CPU and RAM use, because the operating system and background processes are always running. It should not be zero.
A3. Why is it important to take the baseline before the change?
Show solution A3
A3. Without a baseline you cannot tell whether a number is high or low, or what your change caused. The difference between the readings is the result.
Level B: Application
B1. Open one large application and wait for it to finish loading. Record RAM in use and CPU use. By how much did RAM in use change?
Show solution B1
B1. Your own values. RAM in use normally rises after opening a large app, because the program and its data were copied from storage into RAM and the new process asked for memory.
B2. Find the processes belonging to that application. How many are there, and what are their PIDs?
Show solution B2
B2. Your own values. Check that the PIDs are different from each other. One application may have one process or several.
B3. Close the application and record RAM in use again. Did it return exactly to the baseline? List two normal reasons it might not.
Show solution B3
B3. Your own values. It may not return exactly. Normal reasons: the operating system keeps recently used data in free RAM, background processes changed in the meantime, or a helper process of the app is still running.
Level C: Challenge
C1. Write three sentences, one each for the RAM, the CPU, and the process, explaining what you observed. Use the words storage, RAM, CPU, operating system, and process at least once each.
Show solution C1
C1. Example: "Storage held the application. When I opened it, the operating system copied it into RAM, so RAM in use rose. The CPU rose briefly while the process ran its start-up instructions and then fell back. The process is the running copy of the application, and when I closed it the operating system took back its memory."
C2. Repeat the measurement with a different kind of application (for example a browser instead of an editor). Which used more RAM? Which caused a bigger CPU jump? Be careful to say "on my machine, in this test".
Show solution C2
C2. Your own values and comparison. A good answer names both apps, reports the numbers for each, and states that the comparison applies to this machine and this test.
C3. A colleague says "I opened the app, RAM went up by 800 MB, so the app has a memory leak". Explain why that conclusion is not justified and what you would measure to check.
Show solution C3
C3. A rise of memory when an app opens is normal, because it loads into RAM. A leak means memory that grows steadily over time and is never released. To check, record the process's memory at intervals (for example every few minutes) while it is doing the same work, and see whether it keeps growing. One reading proves nothing.
Mini Challenge
Run the experiment a second time with a different app and compare the two:
- Make a table with the same four rows (machine facts, baseline, app open, app closed) for each app.
- For each app, write one sentence per observation explaining it with the terms CPU, RAM, storage, or process.
- Add one more sentence saying what you are not sure about, and how you could check it.
Check your work: you took a new baseline before the second app, you changed only one thing at a time, and each sentence explains why. This record is the evidence for the module lab.
Summary & Next Lesson
Key takeaways
- Measure with four steps: baseline, change one thing, measure, explain.
- RAM in use usually rises when you open an app, because the operating system copies it from storage into RAM and the new process asks for memory. CPU often peaks during start-up and settles afterwards.
- After closing an app, RAM usually falls but may not return exactly to the baseline, for normal reasons.
- An explanation connects each number to a concept: CPU, RAM, storage, operating system, process.
- Fair measurements wait for the numbers to settle, repeat the reading, and use one tool.
Next lesson
That finishes this module. Complete the lab Know your machine, which uses the record you made here, then take the module quiz. Everything later in the course builds on this vocabulary.
Self-check
- Why take a baseline?
- Why change only one thing at a time?
- Why might RAM not return exactly to the baseline after you close an app?
- Which two readings did you record before and after opening the app?
- What is the difference between one reading that is high and a memory leak?
Show answers
- So you have something to compare with, and can tell what your change caused.
- So you can tell which change caused which difference.
- The operating system may keep recent data in free RAM, background processes may have changed, or helper processes may still be running.
- RAM in use and CPU use.
- A leak is memory that keeps growing over time and is never released. One high reading is not enough to show it.
References
- Microsoft Learn, Finding the process ID. It describes opening Task Manager and the Details tab, used in Parts 1 and 2.
- Apple Support, View information about Mac processes in Activity Monitor. It describes the processes list and sorting by column. The exact menu names for the system information screens differ by version and were not verified against every release, so use your system's own search if a menu name differs.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.