5 ms·

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 kno

by jakobe 15y ago

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 profile is useful to the "casual user".

4ad 15y ago
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 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.
- jakobe 15y ago
  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 reason is that an app is accessing a memory mapped file or modifying a copy-on-write page, when underlying reason is that you ran out of RAM. Activity Monitor is perfectly suitable to find out why you ran out of RAM. Oh, Mathematica is using 2GB of RAM? Maybe I try closing that. It doesn't matter if "Real Mem" actually counts some memory twice, it is still a useful measure. EDIT: Yes, I assumed that the problem is memory pressure. Since this is a common reason for "The whole system becomes sluggish", it seemed reasonable to start testing for this.
  - 4ad 15y ago
    Fantastic argument, user is having a problem, but it doesn't matter what's going on, let the user try arbitrary things which I already explained that are folklore and why they make no sense, maybe it works. 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.
    - jakobe 15y ago
      1) Nowhere have I suggested to "kill top RSS process". 2) If you start Activity Monitor, you immediately see if memory pressure could be the problem (well, after 30 seconds, because it takes time to start Activity monitor if you ran out of memory) 3) If you ran out of memory, looking at which apps use much RAM is useful. And it's not as unpredictable as you make it seem. Quitting an app, you'll free at least the private memory, and you might free some of the shared memory, and other processes (e.g. Window server) might also free some more memory as a consequence. This might not be a precise prediction, but it's not quite "impossible to assess". I do not know how prevalent memory pressure is for other users. It's been the primary reason of "sluggish computer" for me. If you know more about this topic, I'd be thrilled to hear other possible explanations beyond "it's more complicated than that".
- scott_s 15y ago
  I do understand how memory works on modern systems, and I agree that Activity Monitor can still be used as a blunt tool. My system (MBP, 4 GB of RAM) works beautifully most of the time, but I noticed that sometimes when I went to a new tab in Chrome, there was a multi-second delay. I opened up Activity Monitor, went to a new tab, and noticed that my disk activity had spiked. I figured that the memory system was swapping in/out a lot of pages, so I looked at rough memory usage, and saw that the Shockwave Flash plugin had close to 1 GB in RSS. I then realized that using YouTube as a music player is probably not a good idea - Flash was designed to run as the main thing you're doing, not in the background while you're doing other things. I killed the tab, and I had no more problems. Blunt tools can still be useful. The problem isn't the tool, it's the knowledge that people have when they use it. For example, I know that RSS overcounts, but I also suspect that the Flash plugin isn't sharing enough to make a big dent in 1 GB. And, it turns out I was right. You wrote an excellent explanation above about modern memory systems, I find it strange that you're harping on this particular point so much.
  - Caballera 15y ago
    Yep, I checked out my Activity Monitor and the Flash Plugin was also the culprit, using over 890mb of RAM. I'm running Firefox with multiple tabs (5), Chrome with multiple tabs (7), pages, X-Lite, Adium, mail and thunderbird and 4GB of RAM with no problems.

by jakobe 15y ago

4ad 15y ago

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 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.

jakobe 15y ago
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 reason is that an app is accessing a memory mapped file or modifying a copy-on-write page, when underlying reason is that you ran out of RAM. Activity Monitor is perfectly suitable to find out why you ran out of RAM. Oh, Mathematica is using 2GB of RAM? Maybe I try closing that. It doesn't matter if "Real Mem" actually counts some memory twice, it is still a useful measure. EDIT: Yes, I assumed that the problem is memory pressure. Since this is a common reason for "The whole system becomes sluggish", it seemed reasonable to start testing for this.
- 4ad 15y ago
  Fantastic argument, user is having a problem, but it doesn't matter what's going on, let the user try arbitrary things which I already explained that are folklore and why they make no sense, maybe it works. 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.
  - jakobe 15y ago
    1) Nowhere have I suggested to "kill top RSS process". 2) If you start Activity Monitor, you immediately see if memory pressure could be the problem (well, after 30 seconds, because it takes time to start Activity monitor if you ran out of memory) 3) If you ran out of memory, looking at which apps use much RAM is useful. And it's not as unpredictable as you make it seem. Quitting an app, you'll free at least the private memory, and you might free some of the shared memory, and other processes (e.g. Window server) might also free some more memory as a consequence. This might not be a precise prediction, but it's not quite "impossible to assess". I do not know how prevalent memory pressure is for other users. It's been the primary reason of "sluggish computer" for me. If you know more about this topic, I'd be thrilled to hear other possible explanations beyond "it's more complicated than that".
scott_s 15y ago
I do understand how memory works on modern systems, and I agree that Activity Monitor can still be used as a blunt tool. My system (MBP, 4 GB of RAM) works beautifully most of the time, but I noticed that sometimes when I went to a new tab in Chrome, there was a multi-second delay. I opened up Activity Monitor, went to a new tab, and noticed that my disk activity had spiked. I figured that the memory system was swapping in/out a lot of pages, so I looked at rough memory usage, and saw that the Shockwave Flash plugin had close to 1 GB in RSS. I then realized that using YouTube as a music player is probably not a good idea - Flash was designed to run as the main thing you're doing, not in the background while you're doing other things. I killed the tab, and I had no more problems. Blunt tools can still be useful. The problem isn't the tool, it's the knowledge that people have when they use it. For example, I know that RSS overcounts, but I also suspect that the Flash plugin isn't sharing enough to make a big dent in 1 GB. And, it turns out I was right. You wrote an excellent explanation above about modern memory systems, I find it strange that you're harping on this particular point so much.
- Caballera 15y ago
  Yep, I checked out my Activity Monitor and the Flash Plugin was also the culprit, using over 890mb of RAM. I'm running Firefox with multiple tabs (5), Chrome with multiple tabs (7), pages, X-Lite, Adium, mail and thunderbird and 4GB of RAM with no problems.