Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A detailed look at memory usage in OS X System
I collected the following illuminative posts from Barry Sharp on system memory management from the Apple discussion boards.

- Dennis Hill

[Editor's note: Dennis suggested I cut this down to a concise summary, but I thought I'd just publish them as they were written by Barry; he obviously has a great deal of knowledge about Mac OS X! These emails were originally sent by Barry to Ted Landau at MacFixIt, and then were posted to the discussion group where Dennis found them. So if you'd like to learn a lot more about OS X's usage of memory, read the rest of this article. It's a bit long, and can get technical at times, but I found it very interesting.]


--------------Email-1

Ted:

Virtual memory (VM) is just what it says -- "virtual" -- it really doesn't exist. The VM size is NOT consuming any disk space.

Unless a user's X system is performing swapping there's absolutely no need to worry about the swap file size nor its location. Swapping activity is provided by observing the "0(0) pageouts" in the last header line of the Terminal top command. Another useful Terminal command is the vm_stat(1) command (see man vm_stat). This command also displays the number of Pageouts. The pageout value is an indication that physical memory is being paged(swapped) to the swap file. This i/o is done in page chunks. A page chunk is 4096 bytes in size.

When physical memory is paged (swapped) to the swap file it is being done so because physical memory is being over-subscribed. The best solution for avoiding frequent over-subscription of physical memory is to have fewer Apps running at same time or install more physical memory. When physical memory becomes over-subscribed the OS will seek out inactive memory pages and copy them to the swap file in order to make room for the active memory pages -- which may have to be copied from the swap file back into physical memory.

Excessive and continuing swapping in a VM UNIX system is BAD and should be avoided at all costs. One has to have a swap file to deal with memory over-subscription.

If a user observes pageouts to be non-zero AND growing rapidly then more memory should be installed or else reduce the memory subscription by running less work in the machine at the same time.

Taking time and effort to place and configure the swap file is for the most part futile and is an attempt to hide the real problem of over subscribing physical memory.

Also, note that in a multi cpu system there's no real concern for swapping activity if while swapping is being done the CPUs are kept busy with other work. Swapping and CPU work can proceed simultaneously. Only when the CPUs run idle waiting for swapping in/out to complete is there a problem with swap performance. In this case placing swap file on a very high-speed device will be beneficial.

My advice for most home computer users of X is to leave the swap file placement and its config alone and concentrate on ensuring the machine has ample physical memory.

I've been in the supercomputing UNIX business a long time and this aspect of swap file placement and config has been well and truly discussed and the conclusions are as I mentioned above.

If a UNIX system employs non VM for memory management (that is, real memory) the issue of swapping is a different beast altogether. This is because when swapping memory out it has to be done in large contiguous chunks (not small pages of 4096 bytes). For this reason it's important that the swap file space on disk be a contiguous set of tracks/cylinders and if possible have a separate data path to avoid interefering with other user i/o activities.

Regards... Barry Sharp

---------Email-2

Ted:

After sending you my lost post on "Virtual Memory swapfiles and OS X performance" I had some further thoughts related to many people posting

a) no matter how much RAM I have installed the X system appears to need it all

and

b) the X system appears to perform better with increasing time of usage

Although I don't have the X kernel source code I can easily speculate why these statements are being made, and also why they are valid.

First, let's digress just for a moment back to 9.1. In 9.1 there were two configuration options that relate to what's going on in X.

They are the Disk Cache and the RAM Disk features.

The Disk Cache can default to some size or be overridden. This cache is used to hold frequently used disk data or data that simply is being written out to disk. The idea is for the data to be more readily available to Apps when they need it and so avoids data having to be read from disk. Memory-to-memory transfers are very much faster than disk-to-memory and vice versa. The important thing to note here is that this Disk Cache is static. Its size never changes. If you make it large it takes memory away from what's available for Apps. If it's made too small it is ineffective. There's also some danger in caching data in memory and that is, if the system crashes this data may have not made it to disk for safe keeping and recovery after the reboot.

The RAM Disk feature is similar in nature to the Disk Cache in that it's static and takes precious memory away from Apps that may need it. Its usefulness lays in the fact that some App need to reuse their data files repeatedly. If these data files all fit into the RAM Disk then great benefits can be obtained by avoiding the much slower disk data transfers.

In X neither of these features are present on the face of it.

However, X's underpinnings (ie the UN*X kernel) provide both these features without any inputs being needed by the user. It's called the file system buffer cache. The one most significant difference is that the size of this buffer cache is dynamic. It starts of with some small size and can grow and shrink as the i/o demands and Apps memory requirements vary over time.

It's called a 'buffer cache' because it buffers the i/o data on its way to/from the disk. When an App writes data it first will be deposited into the Apps file buffer memory region and will subsequently be requested via library routines to have the kernel (the OS) copy it from the App's buffer to disk. The kernel will oblige and will copy it first to its buffer -- the file system buffer cache. If the kernel requires more room in its buffer cache it will obtain it from the free memory. When this happens the free memory value, in say the Terminal's top command, will immediately show a reduction of free memory. At some later point the kernel will copy this data (referred to has dirty buffers) to the appropriate disk location. I believe the frequency of this being done is 30 secs -- called sync-ing to disk.

As the usage of X increases with time without rebooting the kernel file system buffer cache will fill with the most needed or most frequently used data. This should help explain why some people claim that the system appears to perform better the longer they've been running X. The needed data for doing things (or maybe most of it) is now all resident in memory (the kernel's buffer cache) and doesn't need to be read from disk. This is much much faster.

As mentioned above, the kernel will expand its buffer cache on demand by using the free or unused memory in the machine. This explains that with time (could be a short period of time or a long period of time -- it depends on system usage/workload) the system appears to be using all of the available RAM per the Terminal's top command.

One other point to make is that if the kernel's buffer cache has grown to be quite large and is consuming a large percentage of the installed RAM there's no harm being done. If a new App is launched the kernel will release as much its buffer cache as needed. First it will release parts of the buffer cache that aren't 'dirty' until it figures it can honor the new App's memory demand. If by releasing all the non-dirty buffer segments it still requires more memory for the App then it will start writing the dirty segments of the buffer cache to disk and releasing their memory which in turn can be given to the new App. This stops when all the memory required by the new App is satisfied. In this manner the kernel buffer cache shrinks down in size. There's probably a minimum size to which it will shrink down to. In this case the kernel will start looking for other memory that's inactive. This could be a dormant App's memory. In this case the kernel will start to page out the dormant App's memory hoping to satisfy the new App's memory requirements. This kernel activity is called paging or swapping.

When the kernel starts to perform swapping it's a sign that the physical memory in the machine has been oversubscribed. Continual swapping will impact the overall system performance -- things will become unresponsive and much disk i/o seeking will be apparent/heard. This type of activity is displayed in the Terminal's top command with the value immediately preceding the "pageouts". If this number is non-zero and increasing rapidly over short periods of time then severe swapping is taking place. This is bad.

If severe swapping is taking place then either more RAM must be installed or the workload in the machine needs to be reduced. Of course the system will continue to run but not at its optimal performance levels.

I believe the above helps explain why people claim the X system performs better over time without intervening reboots and why the system consumes all of memory no matter how much RAM is installed.

A good example of seeing the kernel buffer cache in action is to use the Terminal App. In Terminal perform a copy of a large file. I chose to copy the swapfile as I know it's large (you'll need to be root in order to do this). Also it helps to have a second Terminal window active with the top command running.

localhost% cp /var/vm/swapfile0 ./bigfile

If top showed some 100MB of free memory prior to this copy you'll notice that the free memory falls rapidly to around 4-5MB. This is because the kernel has consumed just about all of the available free memory for its buffer cache.

Now remove the ./bigfile

localhost% rm ./bigfile

What happens in the top display -- well all of a sudden you should see free memory shoot way up. This is because the kernel no longer requires all that space in its buffer cache that's holding ./bigfile AND it doesn't need to write it out to disk BECAUSE you removed it.

So my advice is

a) don't be too worried about free memory being small in the top's display

b) keep an eye on pageouts and if increasing rapidly with time reduce machine's workload or add RAM if workload is a requirement.

c) Don't mess with relocating or sizing the swapfile -- an interesting exercise but really quite futile for the average Joe using X on iBooks, iMacs, etc. You simply should avoid severe swapping at all cost.

One last point -- I speculate that X attempts to always keep a small amount of free memory. I've never seen mine dip below 3MB. I believe this is for avoiding a memory deadlock situation whereby the kernel needs memory to perform a critical function and cannot page any memory out -- a nasty situation.

Some of he following is speculative on my part as I don't have OS X kernel source code nor have I performed any real hands-on experimentation. I leave it to you to figure whether in your case moving the swapfile to a specially configured HD or HD partition provides any benefit. I will offer some suggestions and opinions along the way though.

1. (FACT) Each time X boots it removes any of the swap file segments -- ie swapfile0, swapfile1, swapfile2, ...., swapfileN

2. (FACT) Each time X boots it will create a file /var/vm/swapfile0 that I understand to be 80MB in size.

3. (SPECULATIVE) When X creates the swapfile0 file it may or may not be forced to be contiguous on disk. If not then it will be scattered about on the HD (ie fragmented to a small or large degree -- depends on how fragmented the HD's free space is at the time.

4. (SPECULATIVE) I believe when X pages/swaps memory it does so using well-formed i/o and transfers data in 4096 byte chunks (called pages). The minimum allocation style for HFS+ is 4096 bytes. It's unclear whether X pages/swaps using multiple 4096 byte chunks in a single i/o request. If not, then paging/swapping is done transfering single 4096 byte chunks.

5. (FACT) If the kernel buffer cache has a series of 4096 byte chunks that all map to a single contiguous disk address range then paging/swapping this series of chunks will be much quicker if the kernel organises the series of 4096 byte chunks in the proper order and issues a single i/o request. The same would be true if the data were coming from disk to memory.

6. (FACT) Application's memory can be scattered throughout main memory (RAM) -- it's not necessarily contiguous.

7. (FACT) Many Applications share memory resident re-entrant code fragments with other Applications and or system support programs. Typically these code fragments never get paged/swapped out as they are in constant use.

8. (FACT) If X finds itself having to page-out/in (swapin/swapout) constantly to meet the users memory demands the system's responsiveness will go 'down the toilet' in a hurry.

This activity can be observed by monitoring pageouts in the top display.

A constant stream of pageouts and pageins is not good and means main memory has been oversubscribed. If this is unavoidable for some reason then if X pages out a series of contiguous 4096 byte chunks rather than many individual 4096 byte chunks then having a swapfile that's not fragmented (be it on the internal HD or not) provides some benefit. If on the other hand X always does its swapfile i/o in single 4096 byte chunks then it makes absolutely no difference if the swapfile is fragmented vs. not fragmented (ie a contiguous set of HD tracks/cylinders). However, this situation should be resolved by adding more RAM not by messing with swapfile placement.

Sooooo, if X does insist on having the swapfile0, swapfile1, etc be contiguous it matters not as to where its located -- on the internal HD, a separate internal HD partition, or a separate disk altogether.

On the other hand, if X doesn't insist on having the swapfile be contiguous then only when your system performs severe paging/swapping in/out will having it on a separate partition all by itself or a separate HD used exclusively for swapfile will there be any benefit. I suggest however, that if this is the case you either cut back on the amount of workload in the system or install additional physical memory (RAM) to gain the full performance potential of your system.

It's kinda like the conjestion on the freeways -- if the freeways are conjested the soln is to throttle back the number of cars entering the freeways (ie reduce the workload) or build wider or more freeways (ie install more RAM).

My guess is that when X creates the swapfile on your HD it does so in such a way as to make it contiguous. If this is correct there's absolutely no advantage in placing the swapfile elsewhere.

I will try to find time to explore this aspect of the X default placement of the swapfile(s) later and post back.

Hope this rather long-winded explanation helps some.

Regards... Barry Sharp

I'm speculating and basing my answers on my UNIX OS experiences.

PhysMem is just that -- physical memory -- your installed RAM.

1. Wired = memory allocated that shouldn't/can't be swapped/paged out (ie its locked into memory -- possibly portions of the OS code for example).

2. Active = allocated memory that has been accessed during last N seconds.

3. Inactive = allocated memory that hasn't been accessed during last N Secs (quite likely to be forst candidates for being swapped/paged out if memory being demanded).

4. Used = Wired + Active + Inactive

5. Free = memory that isn't allocated to any process or the kernel.

6. VM = Virtual Memory ( a fictictous amount of memory that represents a processes upper potential limit for its memory allocation or requirements -- very raely ever requested). I'm not sure what the + 44.0M represents.

Remember that the command top shows both instantaneous and historic data. The PhysMem line shows actuals at the time top makes its inquiry to the kernel whereas the pageins and pageouts display activities since the machine was booted. Sooooo at some previous point apparently, in your case, the system/kernel had to swap/pageout some memory in order to accommodate a memory request issued by a user or kernel process.

Hope that was brief enough and helps you understand things better.

Regards... Barry Sharp
    •    
  • Currently 4.22 / 5
  You rated: 1 / 5 (9 votes cast)
 
[141,524 views]  

A detailed look at memory usage in OS X | 10 comments | Create New Account
Click here to return to the 'A detailed look at memory usage in OS X' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
spot on!
Authored by: s2 on Jun 21, '01 05:20:18PM

The words Barry has composed here are entirely true and correct for all UNIX flavours I know. Heed his comments about just leaving things alone, as a general rule output from commands like vm_stat are really only of use if you know:

a) what the system is doing at the time
b) how the kernel behaves wrt the subsystem of interest (this varys with flavour)
c) how the output relates to b) (this is the important part to tuning!)

A word on top though - top is provided in X to show what is going on. It is not perfect, afterall it sucks 10% of my G4 cpu time and is usually at the top of its own table. top is not a suitable tool for tuning, use proper instrumentation such as vm_stat & iostat and do your reading - or go with a well educated guess - that of the developers!



[ Reply to This | # ]
Adding Virtual Memory
Authored by: TheFlib on Jun 27, '01 03:21:38PM

Can someone please tell me how to add virtual memory in X?
Thanks.



[ Reply to This | # ]
spot on!
Authored by: Clint MacDonald on Jun 28, '01 07:35:40PM
A word on top though - top is provided in X to show what is going on. It is not perfect, afterall it sucks 10% of my G4 cpu time [...]

To reduce the usage of the "top" command, type something like:

top -s 5

This causes top to poll less often, in this case every 5 seconds rather than every second. It makes a big difference in cpu usage.


Best wishes,
Clint



[ Reply to This | # ]
Why does it work?
Authored by: bilca on Oct 10, '01 06:07:34AM

In a number of posts (like http://www.resexcellence.com/hack_html_01/09-14.01.html) people have seen speed improvements by using a dedicaded swap partition.

I'm new to the Unix stuff so I wonder this matches with the theory of Barry Sharp (http://www.macosxhints.com/article.php?story=20010613140025184)?

Any coments?

BR, Casper



[ Reply to This | # ]
Why does it work?
Authored by: xeroply on Apr 04, '02 11:17:12PM

Well, Barry Sharp's reasoning is that if the system forces the swapfile to occupy a contiguous space on the disk (as he speculates that it does), then moving it to another disk won't make any difference, since it's equally unfragmented in either place.

However, I think he forgot to take into account I/O competition -- that is, the idea that having the swapfile on a different disk than your system and applications should reduce the time that VM paging operations spend waiting for other disk operations to complete, and vice versa. I don't know how big this difference is, but it could account for people seeing improvements after moving the swapfile.



[ Reply to This | # ]
I/O competition from different disks
Authored by: makip on Oct 12, '04 06:26:45AM

A further clarification: moving a swap file to another disk improves performance if that disk can be accessed independently of the system volume.

SCSI and SATA drives can be read and written to simultaneously on the same bus, but ATA drives cannot, they would need to be placed on seperate busses for a performance increase.

Maki



[ Reply to This | # ]
Why does it work?
Authored by: barrysharp on Apr 05, '02 01:45:50AM

That's really misses the point.

The swap feature is provided simply as 'poor man's memory'. This was when memory sizes were small and was expensive. Today memory isn't small nor is it expensive -- so load up with RAM to avoid your system from ever (well you can't avoid it altogether) swapping under the normal workload you place on your computer.

For example, I bought 1gig of memory about a year ago for $107 (2x 512MB modules for my iMac DV). My system hardly ever swaps out pages as reported by the top command. I run for weeks and top shows '(0)0 pagesouts' for me. This is with me using Virtual PC with Windows XP Professional loaded and using 256MB of memory.

If you can avoid swapping to the extent I have it matters not where the swapfile resides.

My advice to anyone is to load up with RAM and avoid swapping altogether. A system with 1 to 1.5 gig is very unlikely to promote pageouts for the average home computer user. Professional users might/could push the limits though.

Regards... Barry Sharp



[ Reply to This | # ]
Why does it work?
Authored by: jzaw on Aug 21, '02 06:45:34AM

ive read with great interest your initial (long) vm explanations
and agree with and confirm observations of most of what youve said

but ...

can you speculate why my system (osx server 10.1.5) running just the standard file and web servers
and ftp craws to a damn halt when i try to temporaraly run a browser or email client on it

if i use top to see free ram and page outs ... after only a short time ive had 100,000's of page outs and the free ram sits at 9.5MB ish (ive got 768MB real ram installed)

i regularly have 13 swap files in my custom 1GB swap partition
though this figure does rise and fall

ive noticed that each week when the "weekly" script runs
my free ram rockets back to like 350-500MB free

i have done some lengthy observation and ive noticed that
the free ram is gradually eaten up as i tx files to and from the fileserver (via my ethernet lan)
free ram loss is on a 1:1 ratio with tx'd volumes
i can understand caching outgoing traffic (ready should it by chance be requested again)
but why would it need to cache and keep cached any incoming traffic?

if i had to describe the situation
its almost as if the system (kernel?) isnt giving up your "dirty cache" when a new (or old) application requires it

this threshold of approx 9.5MB doesnt seem to trigger any attempts to re acquire useable ram as free ram

the once the real ram is totally subscribed (after 24 hours or less) the system bogs down dramatically
(of course cos its paging in and out)

and whats worse is that this not only happens on OS X SERVER BUT ALSO ON OS X CLIENT (running filesharing)
(if the client has filesharing turned on and i access those files)
my client mac has 1GB of ram and is used mostly for graphics work
if i dont have the client mac do any filesharing then i dont get page outs
if i share files from the client ... i quickly get page outs and swapfile generation on that client
this is defo associated with the "server" action of a mac

tcp traffic seems to do exactly as you describe .... ie eat up the free ram with some sort of caching process
and then doesnt give it up

i have a small lan
2 macs
1 mac server
1 pc
linux box - router/firewall

the server is my graphics filestore
i run the webserver on the osx server to showcase my work to clients
(ie let them see the progress of the order of 100 -500 hits per week )
i run ftp from that same server to tx finished work to the client (once or twice a week)

the osx server mac is hardly taxed greatly ...
so the instruction to reduce its work load ... well i wouldnt know where to go with that?


any speculations as to why or how this is happening
any speculations as to what i can do to improve the system performance
i understand that a server is in the main not suposed to be used interactively on a regular basis
however as a lot of ppl dont have osx server and use a client os to share files this sort of slow down wouldnt be acceptable

and i do occasionally do that too

if you need any more info pls dont hesitate to ask
thanks in advance

Zaw



[ Reply to This | # ]
Why does it work?
Authored by: gedboy on Oct 18, '04 06:54:11AM

jZaw I reckon I have a similar problem. I came across this via the Apple website btw.

G5 1.8 MHz DP with 1.5 GB of RAM running 10.3.5

My G5 has started crashing and needing a force restart in the last three weeks. I at first blamed Safari, then Eyetv but after a system reinstall and archive over the weekend the problem remains. Firefox has crashed it, as has iTunes but it could be any programme at this stage. Everyone is a suspect.

Looking at the Activity Monitor there are a few strange things. Generally I have about 1.1 GB free and almost no page outs. If I run something like Poisoned the giftd process takes 90% of the CPU and Inactive Memory zooms up to about 1 GB, leaving about 17 MB Free. Pageouts start climbing and the G5 hangs after abotu three minutes.

In Safari the same thing happens (except for the outrageous CPU usage) and eventually a hang is caused. Apart from the amazing speed with which Poisoned gobbles up CPU and RAM I can't exactly see a link in what's happening.

Currently Inactive RAM seems to be hovering on about 146 MB, going up AND down by about half a MB so this is cool but I only have Mail and Safari running beyond the normal system processes.

So the only thing I can see on my machine is that for some reason in some circumstances my Inactive RAM goes up until all my RAM is used then memory swapping starts until the system falls over. What is it that prevents Inactive RAM returning to Free RAM, or does that not happen anyway?

I will keep experimenting with combinations of programmes to see if there is an interaction between them that's doing it but this is driving me nuts. I even managed to crash via the Activity Monitor this morning.

In the good old days (last month) I could cheerfully have twenty programmes open and not be bothered.



[ Reply to This | # ]
Why does it work?
Authored by: clith on Jan 18, '07 11:15:23AM

And yet, here I am in 2007 with a dual-dual-core cpu Mac Pro with 2 GB of RAM and my machine swaps madly sometimes, so now I am thinking of upgrading to 4 GB!

How are you guys in 2012 doing with your 16-core 8 GHz machines? I'm guessing 64 GB is good for you.. :-)



[ Reply to This | # ]