Ask HN: How does the Activity Monitor in OS X calculate memory usage?
Ok, I am asking this here because I came up empty on Stack Overflow, Super User, and Google. How the hell does the Activity Monitor in OSX 10.10 calculate memory usage. The numbers from sysctl and vm_stat match each other (I assume vm_stat just pulls the numbers from sysctl), but those results are always higher by 10-20%, compared to what Activity Monitor reports. So, who is lying to me, the Activity Monitor or sysctl?
1 comments
You can use otool to see what libraries a program uses:
$ otool -L /Applications/Utilities/Activity\ Monitor.app/Contents/MacOS/Activity\ Monitor
/Applications/Utilities/Activity Monitor.app/Contents/MacOS/Activity Monitor:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1153.20.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1348.13.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57031.30.5)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/PrivateFrameworks/GraphKit.framework/Versions/A/GraphKit (compatibility version 1.0.0, current version 25.0.0)
/System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation (compatibility version 1.0.0, current version 55126.0.0)
/System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport (compatibility version 1.0.0, current version 631.0.0)
/usr/lib/libsysmon.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/NetworkStatistics.framework/Versions/A/NetworkStatistics (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1153.18.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 62.0.0)
$ otool -L $(which top)
/usr/bin/top:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.14.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libpanel.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)They both use libSystem.B.dylib, other then that, I don't see significant overlap. But everything under the sun uses libSystem.B, so that's no help. I am pretty sure that top pulls the data from sysctl. Apple must have come up with some "clever" way of calculating memory. The only thing I can think of is that they are reporting compressible memory. Meaning that if the system was short on RAM, it could say compress the 8 gigs of ram down to 5 gigs, but they are not doing so no, because that would be a waste of CPU cycles.