Diff.between "available" and "free" physical memory?

Welcome to the Seven Forums.

Have you applied this hotfix?
http://support.microsoft.com/kb/2155311/en-us

edit: see this post for more info.

I don't see this hotfix under installed updates, but it's not clear if my processor (i3-2350M) is NUMA-based and therefore affected.

Is it likely that my machine suffers from this problem regardless?

Layback Bear said:

Did you have this problem before Windows Enterprise was installed?
Where did you get Enterprise from?

I work for a federal gov't agency and our desktop support people upgraded me to Win 7 about 6 months ago. I had never heard of Windows 7 Enterprise before.

I only ran Win XP for a short while after I received this laptop so I can't be sure of the genesis of this problem. All I know is that, when I start up a print job or a new app, it's a pig, with not responding showing up in various title bars.

coghlan said:

I don't see this hotfix under installed updates, but it's not clear if my processor (i3-2350M) is NUMA-based and therefore affected.

Is it likely that my machine suffers from this problem regardless?

The i3 family of CPUs is not NUMA based... so no need for the hotfix. You might want to consult with your IT department about which processes can be prevented from automatically loaded... or get more RAM as you mentioned

Of course, more RAM can reduce battery life :-(

Having a significant amount of free memory is neither necessary nor desirable. The OS was designed to operate with little or no free memory, this in fact being the optimum situation. The important number is available memory and this seems to be quite adequate. Having a large number of page faults in itself is not a bad thing as most are likely to be soft faults which require no disk access. Based on the information provided there seems little reason to believe the problem is memory related.

Here's a screen shot of over 700,000 page faults/sec, however, I notice that the peak commit charge (apparently RAM + paging file used) is 2.4Gb, so I presume nothing is being paged to disk.

Is it safe to assume that if peak is below the amount of physical RAM, adding more memory isn't going to help prevent the extreme sluggishness I see at various times during the day?

Here's a screen shot of over 700,000 page faults/sec, however, I notice that the peak commit charge (apparently RAM + paging file used) is 2.4Gb, so I presume nothing is being paged to disk.

Is it safe to assume that if peak is below the amount of physical RAM, adding more memory isn't going to help prevent the extreme sluggishness I see at various times during the day?

No

The idea that if peak commit charge is less than RAM size then no paging will occur is one that is often seen. But the concept is based on a flawed understanding of what commit charge means and has no real validity. Commit charge is NOT a measure of RAM usage, pagefile usage, or any combination of the two. There really is no direct relationship between commit charge and performance. It is possible to have a high commit charge with good performance. It is also possible to have a low commit charge and poor performance. The commit charge is important but all you really need to know is to ensure that the commit peak is well below the commit limit. A high commit charge could also indicate a memory leak but there is no evidence of that here. Understanding the commit charge is complex and I won't attempt to explain it here.

The number of page faults is very high but clearly they are of the soft variety and do not involve disk access.

This is something that really needs to be looked into by the IT staff.

I think I'm on my own w.r.t. this issue. We don't get much more than component swapping from our desktop IT people.

I was recently given a copy of this process explorer tool, so when I start seeing performance degrade I will try to get a better idea of what is happening. I know that CPU usage is not excessive (<50%), and things tend to go south when I start a new activity (print a PDF, open Word etc.), so it's somehow related to things being loaded into RAM.