Earlier quoted context omitted.
Activity Monitor is a tool too blunt for these kind of scenarios. It pains me, Mac OS X has DTrace which makes it a breeze to find out what really happens, however, the only GUI tools built on top of DTrace are profiler for programmers, nothing for the casual user. Activity Monitor presents data that's not really useful and does so in an intrusive manner and in a confusing display. Mac OS X already comes with parts o…
If your problem is that you are running out of RAM, Activity monitor will tell you precisely what app is the culprit. Nothing "blunt" there. If you want to know why a specific app is frozen (beachballing), you can click the "Sample Process" button in Activity monitor to perform a time profile. Yes, if you want more details, you have to use Instruments or write your own DTrace scripts. But I doubt that even a time pro…
The "real memory" column is resident set size, a completely useless metric for the problem at hand because of many reasons. One reason is that much of the physical pages can be shared, indeed most of them usually are, on my system a chrome process has a 120MB RSS, but after closer inspection 110MB is shared, and after even closer inspection 90MB is shared with non-chrome processes. Closing the process with top RSS usage might do very little for decreasing memory pressure. Another reason is that physical memory usage is very misleading, if the system is swapping, a process has less resident physical pages than the virtual pages it uses, that's the reason the system is swapping in the first place! A process can thrash memory and have a relatively small RSS.
You also simply assume what the problem is without actually testing for it. You need to look why the system spends time in kernel mode, maybe it's not swapping, most likely is not swapping in this particular case, it's more likely to be the random I/O caused on-demand paging of memory mapped things or something more subtle, like copy-on-write pages being written to. It also could be a million other things.
Even if the problem is caused by memory pressure, memory pressure is a remarkably generic term, the VM system has many components and different components are affected by different workloads. A simple metric like RSS can't tell much.
Yes, Activity Monitor is very blunt tool.