Memory Leaks in Mac OS X

Recently Apple released a version 10.2.6 update for its Mac OS X operating system. According to certain internet buzz, this update does more than provide bug fixes and security patches. It purportedly causes a near-runaway condition called a memory leak. A problem that transcends the boundaries between operating systems, the solution may be to wait for the next great patch to fix the last one.

Or not. The problem can be caused by an application. Finding it can be interesting. In a few of the Macs that I have my hands on routinely, there is a full complement of physical RAM installed. Time was, I'd never dream that a computer could even hold a gigabyte of physical memory, much less use it all up. Now I routinely observe these machines dipping into page RAM, the virtual memory created by reserving some disk space and using that to spoof real memory.

Page RAM is something like the reserve fuel light on many vehicles. It's okay for it to light once in a while, but you'd better fuel up again pretty soon. Likewise, paging is fine for applications that are sleeping, and is a normal part of efficient operation, but you're in trouble if your machine is paging continually. You'll know when this happening, because your hard drive will be rattling endlessly, as does mine eventually, trying to escape the confines of its cage.

Now, this latest buzz is interesting. I always expected OS X to use more memory than, say, Windows 98, and substantially more than its predecessor, Mac OS. It should. But having thirteen megabytes free on a system that has a gigabyte installed is disconcerting. That's how it often is on my home machine, a 500MHz iMac G3 with 1GB of RAM in it and lots of hard disk space, and how it's been for a long time. For me, at any rate, this new update has nothing to do with the matter.

Before going further, let's define the term. A memory leak is a loss of computer memory due to either an application failing to return all its memory resources back to the operating system as the application closes, or an application that uses memory so inefficiently that it keeps using the stuff until there is none left. The source of a memory leak could be an application as well as a component of the operating system. In short, memory leaks can be difficult to trace.

One of the benefits of the internet is the shared experiences of a critical number of users. If many users concur that there is a problem since installing the Latest and Greatest update, then there is probably something to it. If only I notice a problem, then the first place I should look is on my own machine. I run a few Carbon applications ported from their Mac OS counterparts, applications such as Internet Explorer and Eudora Mail. Without a doubt they use more memory than those earlier versions, though, to be fair, quite a number of features have been added to them in the interim also. The solution to a localized memory leak problem is a painstaking but systematic procedure of turning off one application at a time for a period of time, and observing and recording the results.

OS X comes with standard unix tools for observing resource usage, as well as a couple of OS X ones, located in the Applications/Utilities folder. I refer to CPU Monitor and Process Viewer. Open CPU Monitor now, if you like. It has both a real-time CPU usage gauge and a CPU usage chart available from its processes menu, as well as a cute floating bar graph. From the same menu you can find both Process Viewer and a unix utility called Top, which runs in a spawned Terminal window. A Ctrl-C will stop Top from polling.

It's that last one which is of particular interest right now, because it lists a summary of useful parameters at the top, including physical memory usage and pageouts to virtual memory on your hard disk. For example, I have had Top running for the last number of hours, so it's been up all the while I've been typing. Free physical memory started out at a modest 60MB, but as I write is now down to 36.8MB and dropping. I don't think I used 23.2MB of memory in typos.

For quite some time I have been using a memory tool call MemoryStick. This is a nice OS X program that displays memory usage in a bar graph. It's unobtrusive and useful. Another utility recently brought to my attention is MenuMeters, a neat freebee that runs as a system preference and displays resource parameters in the application menu bar, next to your clock.

Do I Need More Memory?

While I was visiting VersionTracker, I also came across dinmm, which expands to Do I Need More Memory, written by the author of another great program called iSwipe. Dinmm displays the same information as Top, with additional calculations and alerts based on applications you open since Dinmm started and whether or not you go over the top on RAM usage.

All of these tools require resources themselves in order to run. So, while they're interesting to watch and very useful for diagnosing a problem, you may need to strike a balance for how you use them, particularly on an already-overworked machine. Also check exactly what parameters each measures. It may not be quite what you think. MenuMeters, for example, presently reports 413MB of free RAM on this machine, where Top is displaying a mere 26MB. It isn't that one is right and the other wrong; it's a question of exactly what is being measured and how. Remember, you use these things to solve a problem, not to create diversions.

A generous reader alerted me to a related issue called vnodes, a type of resource used by OS X. Basically, if you run out of these, your machine will struggle. Thanks to SJ, here is a relevant Apple Support list discussion about vnodes. The numbers given therein are for a representative machine with 1GB of RAM installed. After it's been running for a while, check your own machine for how many vnodes are available. Do this in a Terminal window with these commands, gleaned from that discussion:

pstat -T
sysctl kern.maxvnodes

The default is 17200. If your Mac is using close to the maximum, you'll probably benefit from the tweak suggested in the discussion. I experienced a pronounced performance and stability boost by applying it to my systems. To make this tweak, you need to do a privileged edit. One method of editing a system configuration file such as rc is to start TextEdit like so:

sudo /Applications/ /etc/rc

Some have suggested using the simpler sudo open -e command, but I have yet to gain sufficient file access privileges for it to be more helpful than copying and pasting my admittedly lengthy command to a Terminal prompt. Your mileage may vary. Be sure to close this copy of TextEdit with a Cmd-Q when done.

In the last analysis, if the buzz is right and OS X does have inherent memory leaks, we will just have to wait for a patch from Apple. Meanwhile, there is a lot one can do to trace down memory leaks originating in an application. Tracing memory leaks is something like taking aim at a moving target. Consistency and a few good tools - including a pencil and legal pad - can get you closer to a resolution. Good luck. Ciao.