The lab freeze: RAM, disk or both?
St Nicholas College's computing lab has 28 identically configured PCs: 8 GB RAM, a 1 TB 7200 rpm hard disk, Windows 11 and a 4-core CPU. Students use an IDE, a browser with up to 15 tabs, and a school VLE. Teachers report that after about 20 minutes, opening a new project can freeze the machine for 30–45 seconds; Task Manager shows RAM at 7.4 GB, CPU at 25% and disk at 100%. The lab has €4,200 for hardware. A supplier quotes €58 per 8 GB RAM module and €64 per 512 GB SATA SSD; the machines have four RAM slots, two free. The network switch is 1 Gbps and the file server is rarely above 20% utilisation. One teacher argues that RAM is the problem because 'the bar is nearly full'; another says the disk light is always on, so SSDs are the fix. The principal wants a decision before the next intake.
1. Using the evidence, identify the most likely bottleneck and recommend how the €4,200 should be spent. Justify your answer with reference to the symptoms and to the likely effect of each upgrade.
Read the worked answer
For the workload described, the machine is short of usable RAM and is paging heavily. RAM sits at 7.4 GB of 8 GB, so Windows cannot keep the IDE, browser tabs and VLE in memory; it evicts pages to the page file. Every eviction and reload is a random read/write, and a 7200 rpm HDD can handle only around 75–150 random IOPS, so the disk queue reaches 100% while the CPU is idle at 25%. The disk light is therefore a symptom of paging, not proof that the HDD alone is too slow.
The RAM bar being nearly full is also not conclusive by itself: Windows uses free RAM for cache, so a full bar can be normal. But here it is combined with a very high commit charge and constant paging.
Budget: 28 × €58 = €1,624 for RAM; 28 × €64 = €1,792 for SSDs; total €3,416, leaving €784 for cloning, caddies and labour. Both upgrades are affordable. I would do both: 16 GB removes most paging, and an SSD makes any remaining paging and boot/login far faster. If only one could be funded, the SSD gives the bigger visible improvement for a 7.4 GB working set, but it does not fix the underlying shortage. Doing RAM alone leaves the HDD as a slow boot and project-load device.
2. Explain why a nearly full RAM bar is not by itself proof that RAM is the only problem, and describe measurements you would take before and after the upgrade to confirm the fix.
Read the worked answer
A full RAM bar can simply mean Windows is using spare memory for the file cache; it becomes evidence of a shortage only when it is paired with a high commit charge and hard page faults. The CPU at 25% and disk at 100% point to waiting on storage, which is consistent with paging but could also be caused by antivirus scanning or a failing disk. You need to separate those causes.
Use Resource Monitor or Performance Monitor and record: hard page faults/sec, commit charge in GB, disk queue length, average disk response time, and the top processes by disk I/O. A high hard-fault rate with a long disk queue confirms paging; heavy disk use by the antivirus process would suggest a different fix. Also check the disk's SMART health and run a baseline task: open the same project, load 15 fixed tabs and build, five times, recording the median. After the upgrade, repeat the identical task. Success would be commit charge comfortably below physical RAM, near-zero hard faults and a disk queue below about 1, plus a much shorter median open time.