Re: Why is OS X swapping with inactive memory available?
Re: Why is OS X swapping with inactive memory available?
- Subject: Re: Why is OS X swapping with inactive memory available?
- From: Terry Lambert <email@hidden>
- Date: Thu, 29 May 2008 21:23:27 -0700
On May 29, 2008, at 8:02 PM, Jeff Stearns wrote:
On May 29, 2008, at 7:07 PM, Terry Lambert wrote:
On May 29, 2008, at 2:11 PM, Dan Shoop wrote:
On May 28, 2008, at 3:36 PM, Thomas Backman wrote:
Nobody?
This is very annoying... I rebooted 40 minutes ago. Since then I
started a VM with 640MB RAM (in VirtualBox, rather than VMware),
iTunes, Firefox etc. Current RAM stats:
Free: 25MB
Inactive: 1.12GB
Wired: 891MB
Active: 1007MB
Page outs: 25MB (it stopped paging when I quit Firefox)
Why is it swapping with 37% of my total RAM inactive?! I just
don't get it. Stuff starts beachballing at random, etc.
I'm starting to seriously consider switching to another OS
because of this. I can't use virtual machines anymore, and that's
not the only problem, either... Needless to say it happens
without them, too, sooner or later... :(
I realize this isn't really the "OS X support" list, just figured
people here might know what's going on.
Your presumptions about how VM [virtual memory] works on OS X are
inaccurate, which is resulting in misconceived beliefs as to what
occurring. You might consider reading Amit Singh's excellent Mac
OS X Internals book.
As for your "beachballs", these are (most generally speaking) not
caused by VM paging/swapping, but by other IO subsystem waits.
Indeed I'm not even sure VM paging could ever incur a beachball.
If you're seeing beachballs look for why your IO is stalling.
"Spin Control" can help you here.
If you're using virtual machines, this can explain, perhaps, why
you're seeing a high than normal incidence of beachballs since (a)
your IO subsystem isn't 'real', and (b) you have other virtual
machines competing for your real IO subsystem. Both of these could
contribute your your observed waits.
Again, "Spin Control", the tool, can assist you in determining
what these beachballs are caused by and could lead you to a
solution.
And the "beach balls" are actually because the "are you alive?"
messages being sent to the applications run loop by the window
server (which is what controls the mouse curosor) are not responded
to.
The "beach balls" are typically caused by doing blocking work in
your application run loop, instead of marshalling that work off to
another thread to get it completed there, instead. Because of
that, the run loop is not reentered at the top often enough to
respond to the events. So it's usually an indicator of an
application design issue.
Pot, meet kettle.
My MacBook Pro runs a vanilla collection of programs on OS X 10.5.2
-- Mail, Safari, Address Book, iTunes, TextWrangler. I don't have
VMware or Parallels or Boot Camp or any other virtual anything
installed. (And no, I don't run Time Machine at all; too many
slowdowns.) I maintain a very vanilla system. I keep it clean. I
like simple, reliable computers.
Although the computer has 3GB of RAM, it readily goes into fits of
swapping. (Safari is an obvious culprit; it has a voracious
appetite for VM.) At the moment, the computer has 3GB of swap data
spread across 10 swap files. And, yes, I get beachballs from
standard Apple programs (Mail is especially likely to beachball).
It's ironic that my laptop is more prone to slowdowns than my Linux
box, which has 1GB of RAM. But I like the Apple user interface, so
I tolerate the swapping and the beachballs.
If it's a real bug, then no one on this mailing list can help you
without a bug report off which to hang a code change check-in.
No bug report == no code change.
A posting to this mailing list is NOT a bug report.
See <http://developer.apple.com/bugreporter/>.
-
Realize that an "ideal application" from the "beach ball's point of
view" is one which farms out the work on its main run loop so that it
can always respond to "are you alive?" messages. The intent of doing
that is to keep your user interface alive, even if the machine is so
overloaded you can't get any work done: even so, the menus will "menu"
and the windows will iconify and deiconify, etc.. So in the limit, a
"beach ball" means "this application's thread which manages its UI
elements is potentially unresponsive". People have argued for _years_
as to how long until you put up the beach ball.
So it's possible to write your applications to avoid the "beach ball":
just keep your main application loop responsive. Of course a
responsive UI does not necessarily equal a responsive application, and
there are plenty of ways to shoot your foot off in the non-UI code
that will prevent anything from actually happening when you scroll
your scroll bar or click your radio button. Don't do those.
If you can demonstrate that the machine is in fact spending its time
swapping, instead of just assuming it's swapping because you see a
"beach ball" and large swap files, and then assuming that magically
means "waiting for swap to get done", then please file a bug report,
and include your data which demonstrates that this is what is happening.
Another thing that could help you diagnose your problem is the
"spindump" command, which is capable of dumping the thread stacks for
an unresponsive application any time it becomes unresponsive, or all
thread stacks for an unresponsive system.
I suspect that if you run "top", you will find that something is
eating all the cpu time, and that if you solve that problem, you will
solve your general problem.
Either way, if you identify any problems, file a bug report; no matter
how sympathetic someone is, it won't get fixed without one of those.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden