Why one number is never enough
The central lesson is that no single figure proves a RAM shortage. MakeUseOf says a low Available figure on its own can be a passing blip. It becomes a real shortage only when it appears alongside a slow PC and heavy paging.
That matches what other Windows explainers say. How-To Geek lists the real warning signs as committed memory near the limit, stuttering when switching applications, and long delays opening new programs. In other words, the symptoms and the counters have to agree.
1. Available memory, not Free
Task Manager's Memory page has no "Free" headline figure. It shows Available, which MakeUseOf describes as how much memory Windows can hand to a program right now. Available is Free plus Standby. Free is RAM nobody is using. Standby is cached data from recently used apps that Windows can reuse the moment something needs the space. Microsoft's memory-footprint documentation defines Available the same way, as free plus standby pages.
A tiny Free number is therefore normal. Windows deliberately fills spare RAM with cache.
For a finer breakdown, press Win+R, type resmon, and open the Memory tab. Modified pages hold changed data waiting to be written to disk. They are not counted as Available.
One caveat comes from Microsoft's older performance-monitoring guidance. Under pressure, Windows tries to keep a fraction of RAM available by pushing idle pages to the page file. That means the Available counter rarely hits zero and isn't a perfect shortage indicator on its own. Treat it as the first check, not the verdict.
2. In use (Compressed)
In use is the RAM currently occupied by apps, Windows and drivers. The figure in brackets is the compressed portion, and it is already counted in the main number. Windows compresses rarely used data and keeps it in RAM instead of writing it to disk. Decompressing costs some CPU time, but that is still faster than a trip to storage.
How-To Geek makes the same point: high standby memory and high compressed memory aren't problems as long as your system remains responsive. MakeUseOf is explicit that no percentage separates healthy from unhealthy. A PC at 85% In use that feels snappy is simply Windows using the memory you paid for.
3. Committed and the commit limit
Committed appears as two numbers, such as 18/34 GB. The first is what Windows has promised to back. The second is the commit limit. Microsoft's page-file documentation defines the limit as physical memory plus all page files combined.
MakeUseOf uses a hotel analogy for this. The limit is the number of rooms, and Committed is the bookings accepted. Plenty of guests never show up, but if they all do, Windows has to honor every booking.
This explains why Committed can exceed installed RAM without trouble. Committed memory can be backed by RAM or by the page file, and not all of it is resident in RAM at once. A developer walkthrough from Scorpio Software shows the effect: most of a large allocation may not be in RAM right now, but it still counts towards the commit limit.
The danger zone is the limit itself. Microsoft says that if the commit charge reaches the limit, the system and processes may fail to get committed memory. That can cause freezing, crashing and other malfunctions. The same Microsoft page adds a useful detail: system-managed page files automatically grow when the commit charge reaches 90% of the limit, provided there is enough free disk space.
Some outlets offer rule-of-thumb bands. One MakeUseOf piece calls below 70% comfortable and above 85% aggressive reclaiming. Treat those as one writer's experience rather than Microsoft guidance.
Don't disable the page file
The old tip to switch off the page file for speed backfires. It shrinks the commit limit, so you can hit out-of-memory errors even when RAM looks fine. Microsoft also notes that page files can back system crash dumps. Even on machines with lots of RAM, the reason to configure one hasn't changed. Microsoft gives no single ideal size, because it depends on workload.
4. Pages Output/sec
This counter isn't in Task Manager. To add it:
- Click Start, type
perfmon, and open Performance Monitor. - Under Monitoring Tools, select Performance Monitor.
- Click the green plus icon, expand Memory, and choose Pages Output/sec.
- Click Add, then OK.
The counter shows how fast Windows writes changed pages to disk to free RAM. Microsoft's guidance calls it the best counter to watch if you suspect paging is your bottleneck. It also gives a useful corrective: even if Committed Bytes exceeds installed RAM, a Pages Output/sec that is low or zero most of the time means no significant RAM-related problem.
Watch the graph over time, since the occasional spike is normal. The companion counter, Pages Input/sec, shows pages read back from disk to resolve hard faults. That is the cost of needing data you previously pushed out.
Be careful with the combined Pages/sec counter. Microsoft's guidance calls it one of the most misunderstood measures, because paging isn't only about memory over-commitment. A Microsoft BizTalk-era analysis tool flags values above 1,000 as concerning. That is server-oriented guidance and should be read with the Available and commit readings, not as a hard line for a laptop.
5. Working set and commit size
The first four readings say whether there's a problem. Process memory tells you who is causing it. Task Manager's Processes tab shows a Memory column for each program's private working set, meaning the memory it privately uses that is currently in RAM. Adding up that column won't match In use, because shared memory, Windows itself and drivers sit outside it.
Browsers are the classic case. Chrome splits into many processes, so judge the group total rather than any single row.
For the fuller picture, open the Details tab, right-click a column header, choose Select columns, and add Working set and Commit size. A small working set doesn't prove an app is light, because Windows trims idle apps. Commit size is the better leak indicator. Microsoft's leak-troubleshooting guidance says the default column isn't the one to focus on. It says to check Commit size instead, because it covers virtual memory whether it's backed by RAM or the page file. A commit size that keeps climbing during steady use is suspicious. One that is large but stable is normal.
A quick triage table
| Symptom | What to check | Likely meaning |
|---|---|---|
| Apps stall when switching | Available, then Pages Output/sec | RAM shortage if both agree |
| Memory error while RAM looks free | Committed vs. commit limit | You've hit the commit ceiling |
| Browser or fans going wild | Processes tab sorted by Memory | A heavy app is the cause |
What to make of it
The guide's strength is its restraint. It teaches readers to correlate readings instead of panicking at a percentage. Its limits are worth stating plainly:
- It sets no universal thresholds, which is honest but leaves beginners to judge for themselves.
- Several Microsoft counter definitions come from Windows Server and older documentation. The concepts hold on Windows 10 and 11, but Task Manager layouts and column names can vary by version.
- Slowness isn't always memory. A slow disk or a CPU bottleneck can feel the same, and if Committed has plenty of headroom, look elsewhere.
The practical routine is short. Check Available, then how the PC feels, then Pages Output/sec over time. After that, compare Committed to its limit and sort processes by Memory and Commit size. If those signals agree, more RAM is a reasonable purchase. If they don't, you may have saved yourself a trip to the checkout.