4 ms·

Open activity monitor, and check which applications use a lot of memory. (Look at the "Real Mem" column). If your computer frequently freezes, the problem is m

by jakobe 15y ago

Open activity monitor, and check which applications use a lot of memory. (Look at the "Real Mem" column). If your computer frequently freezes, the problem is mostly a specific application (Virtualbox comes to mind), not just Mac OS X itself. 4GB are more than enough for casual browsing.

4ad 15y ago
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 of the DTrace toolkit, you can install whatever you're missing: http://www.brendangregg.com/dtrace.html#DTraceToolkit http://www.brendangregg.com/dtrace.html#DTraceToolkit. These tools allow a very deep understanding of performance problems.
- hazov 15y ago
  Well, I know the basic about SystemTap, but I'm not so much familiarized with low-level stuff, I'll look for DTrace to see what's happening. Thanks for the information.
  - 4ad 15y ago
    SystemTap is a Linux thing, which you can use on Linux to see how this works, but it won't be a pleasant experience. DTrace is also available on FreeBSD, so if you look at what happens on Mac OS X, it might be helpful or insightful to also look at what happens on FreeBSD.
- 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.
- blktiger 15y ago
  Activity Monitor is way older than DTrace and I don't think Apple has made any code changes to it in a long time.
- Zev 15y ago
  The casual user doesn't know what any of the words in your post means.
wvs 15y ago
The private memory column is likely a better measure when looking for memory hogs.

by jakobe 15y ago

4ad 15y ago

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 of the DTrace toolkit, you can install whatever you're missing: http://www.brendangregg.com/dtrace.html#DTraceToolkit http://www.brendangregg.com/dtrace.html#DTraceToolkit. These tools allow a very deep understanding of performance problems.

hazov 15y ago
Well, I know the basic about SystemTap, but I'm not so much familiarized with low-level stuff, I'll look for DTrace to see what's happening. Thanks for the information.
- 4ad 15y ago
  SystemTap is a Linux thing, which you can use on Linux to see how this works, but it won't be a pleasant experience. DTrace is also available on FreeBSD, so if you look at what happens on Mac OS X, it might be helpful or insightful to also look at what happens on FreeBSD.
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.
blktiger 15y ago
Activity Monitor is way older than DTrace and I don't think Apple has made any code changes to it in a long time.
Zev 15y ago
The casual user doesn't know what any of the words in your post means.

wvs 15y ago

The private memory column is likely a better measure when looking for memory hogs.