Earlier quoted context omitted.
Sorry, but no, you're just illustrating the problem I've mentioned. In a virtual memory system with on-demand paging, memory mapped I/O, shared libraries and copy on write pages even measuring and interpreting memory stats is very difficult and subtle. 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 pag…
You are missing the point. The idea is not to determine exactly what's going on, because that doesn't matter. You mentioned the casual user before, but all these details are only important to specialists trying to debug an issue with a specific application. When you run out of RAM, it is completely irrelevant which application is thrashing, because the problem is that you run out of RAM . It doesn't matter if the rea…
If that's you advocate, let's stop here with this discussion, as there's no common ground.
When you're having a problem, first you try to understand it in order to try to solve the root cause. Applying rules of thumb like "kill top RSS process" are as sensible as rules of thumb regarding running repair permissions, sizing paging files or hoping arbitrary herbs cure arbitrary diseases.
Activity Monitor is useless because it's impossible to assess how a specific action will affect the system. Users should understand what's going on when they kill a process and the tools should help them to do so. When people do something, they should understand it, even casual users. Activity Monitor exposes data that's not understood by most users, although it leaves the impression that it does.
Just for trivia, memory pressure, hasn't been the primary reason for "the whole system become sluggish" for a few years already.