
Something is deeply broken in OS X memory management - fields
http://workstuff.tumblr.com/post/20464780085/something-is-deeply-broken-in-os-x-memory-management
======
w0utert
Not this again, we already went through this a few weeks ago.

Back then, I thought the conclusion was that there is nothing broken about OS
X memory management, and that with every 'fix' you come up with, you will just
introduce another degenerate corner case. The same holds for any OS, trade-
offs are made that may have some negative effect in some cases, to the benefit
of the general cases.

I don't recognize any of his symptoms anyway, and my OS X computers get pretty
RAM-heavy use, with almost always a linux VM open, XCode, Safari with ~10
tabs, iTunes with a few thousand songs, etc.

Edit: Just to be sure I read through some of the links he provides that are
supposed to explain what is going on and why the fix would be of any help, but
nowhere do I see any hard facts that demonstrate what is going on. Only that
he 'saw in vm_stat that OS X was swapping out used memory for unused memory'.
I'd like to see some actual evidence supporting this statement.

~~~
gurkendoktor
The thing is, Lion runs like crap without an SSD or insane amounts of RAM for
many people. It doesn't help if it works for some, or even the majority. If
anything, we need _more_ people digging in OS X internals. I am sorry to use a
tired analogy here, but Vista _did_ work great for many too.

I have two Macs, one brand new, one migrated from SL, and 10.7 Safari was
almost unusable on both until I installed SSDs. If that isn't a negative
effect in _every_ possible use case, then I don't know one. I actually guessed
it was just that Lion inofficially dropped support for HDDs (by removing all
caches or so).

~~~
ComputerGuru
I upgraded to an SSD while on Leopard, and was amazed at the speed. Snow
Leopard continued to impress. Lion slowed things down _terribly_ (even with
the SSD!), but I have good news: ever since Mountain Lion DP2, it's been fast
again.

~~~
gurkendoktor
Yes, I am a fan of ML so far too.

Given that Apple has fixed none of my reported bugs in 10.7, but I can't
reproduce many of them in 10.8, I wonder if it even makes sense to analyze
10.7 anymore - seems it's a done deal for Apple.

~~~
calinet6
This is very good news indeed. I'm okay that they don't backport bugfixes as
long as ML comes out in a reasonable timeframe.

~~~
rrrazdan
ML will be a paid upgrade right? So people who paid for Lion are worth
nothing?

------
mikeash
No actual data, barely any technical discussion at all, mention of "the
garbage collection algorithm" which most likely isn't even being used by most
of the apps running, capped by a total cargo-cult solution... and this is #1
on the front page?

~~~
danieldk
The post is (too) light on information, but I don't dismiss it immediately.
Perry Metzger was very much involved with NetBSD (maybe he still is) as a
developer. He might know a thing or two about memory management ;).

~~~
mikeash
Metzger's post is _much_ more subdued and interesting. IMO it would have made
a much better submission. Link for the curious (it's linked from this
article):

[https://plus.google.com/116685507294337280246/posts/camYp28M...](https://plus.google.com/116685507294337280246/posts/camYp28M9St)

~~~
ralfd
I still don't quite grasp it. He is talking about page outs, but how is
disabling the dyn-pager helping with that? Shouldn't page outs only happen
when RAM is full?

At my machine with 8 GB RAM and uptime of 4 days I have page outs of only 2
_Mega_ byte. And page ins of 2 Gigabyte.

P.S. I subscribe to your blog! * starstruck _

~~~
mikeash
RAM serves (at least) two purposes: holding application data, and caching disk
data. Sometimes it can be useful to swap application data out to disk to make
more room for disk caching. Imagine if you have an app taking up a whole lot
of memory that isn't actively using most of it, and another app reading a lot
of data from the disk. In this case, you'll perform better if you swap out all
that unused data, and use that RAM to cache disk access for the other app.

What he's saying is happening is that the OS is doing this too aggressively,
and that it ends up swapping out data that's actually in use in favor of disk
data which doesn't really need to be cached, which hurts performance.

By disabling the pager, you make it impossible to move application data to
disk at all. This limits the amount of RAM available for disk caching, but if
the OS really is caching too aggressively, that will ensure that it can never
page out useful application data by mistake.

My experience mirrors yours, in that it really doesn't seem to be a problem on
the computers I've used, but that's what he says he's seeing.

Glad you like the blog, but I'm just a regular guy. I put my pants on with a
high speed pants installation robot just like everybody else.

------
xpaulbettsx
The core reason that this happens is that OS X uses a memory management
mechanism called Unified Buffer Cache (<http://kerneltrap.org/node/315> is the
only reference I can find on this).

This seems like a good idea to unify paging and disk cache memory, but it
actually isn't. This means, that if you do a lot of I/O, resident pages (i.e.
your programs) can actually get pushed _out_ of memory to free up RAM for the
disk cache. This degenerates pretty badly in scenarios like using VMs, since
you're also using large sections of mmap'd memory.

This doesn't happen on NT or Linux, because disk cache can only be turned
_into_ memory (i.e. making disk cache smaller), not the other way around; the
policy is "Disk cache gets whatever's left over, Memory Manager has priority"

Unfortunately, the only thing you can really do about it, is have a machine
with a huge amount of RAM, which will kind of help.

~~~
zurn
> This doesn't happen on NT or Linux,

No, NT and Linux also have unified VM. What BSD had pre-UVM was pretty
antiquated.

------
spudlyo
What really needs to happen is that Spotlight and Time Machine need to use
direct i/o (F_NOCACHE) when they read data from the filesystem, this way they
won't pollute the disk cache with their reads and OSX won't swap out a bunch
of pages in response.

I think you could probably hack something together that does this with
DYLD_INSERT_LIBRARIES (OSX's LD_PRELOAD) that would would hook the open system
call and fcntl F_NOCACHE on the file descriptor before it hands it back to the
application.

~~~
lobster_johnson
This is the correct solution. Time Machine and Spotlight should not pollute
the OS cache.

~~~
nirvana
I bet the odds are damn good that neither of them ARE polluting the OS Cache.

That they are is just speculation from someone whose taken his experience and
projected it onto everybody.

Since he's a person who mucks around with random system settings (like the one
in his article) there's no telling what previous damage he's done to cause
this problem.

~~~
spudlyo
You might be right. In my testing, mdworker and friends behave like you'd want
them to, I don't see them polluting the cache on my Lion machine. Haven't
tried time machine yet.

EDIT: I can't get either spotlight or time machine to show any cache polluting
behavior at all, at least not in the way that I run them. I used "mdutil -E /"
to force a re-index of my disk, and I kicked off an initial time machine
backup on a secondary drive I had lying around. I see both backupd and
mdworker doing a lot of disk reads using iotop, but top shows my inactive
memory not really changing as drastically as I'd expect, like if I were to cat
a giant file to /dev/null.

------
tomc1985
I did this for awhile and ran into an interesting (if fatal) edge case:

I use a 1.5tb external drive formatted in exFAT to minimize cross-platform
headaches, and whenever the drive is marked dirty (improper shutdown, eject,
etc), OSX will run fsck_exfat on it before I can use it.

fsck_exfat isn't a huge deal -- or wouldn't be, if it didn't have a nasty
tendency to leak RAM... the moment you plug in, fsck_exfat's footprint climbs
up and up and up... never stopping! Pretty soon it's eaten up 8gb out of my
8gb RAM and poor ol' lappy is unusable.

I can say with authority what happens when you run out of physical RAM in OSX:
_it hard locks_. Nothing works -- no keyboard, no mouse, nothing.

So, if you plug in your large, dirty (you dirty drive you!) exFAT-formatted
external drive, with dynamic_paging switched off, and let fsck_exfat do its
thing, your laptop freezes! Leaving the drive dirty, only to be re-scan on
boot-up... freezing the laptop, leaving the drive dirty, only to be re-scan on
bootup...

EDIT: this is with Snow Leopard...

~~~
andyzweb
exFAT is Microsoft proprietary shit.

~~~
georgemcbay
The problem isn't with exFAT, it is with fsck_exfat, which I'm fairly certain
Microsoft didn't write.

chkdsk on Windows manages to clean exFAT volumes just fine without using up
8gb+ of memory.

~~~
tomc1985
yeah sometimes I'll boot into Windows just to clean the drives :-(

------
DIVx0
I've experienced exactly the same thing that was described in this article.
All the way though to installing more ram and disabling the dynamic pager
(this is a late 2011 mbp).

Like the author I was shocked at how accustomed I was to waiting for an app to
become responsive again. I was trained to wait on the OS to do it's business
before I could do my work. Now things happen as quickly as I can think to do
them, this is how computing should be.

------
bsimpson
I've been a Mac user since the beginning, and by far my biggest frustration is
the perpetual running-out-of-RAM, even when I close basically everything. I
have 4GB of RAM, and frequently catch kernel_task using at least half of it.

~~~
jfb
Why shouldn't the kernel be using as much memory as possible? It's not like
big disk caches or what have you cause your memory to go bad? As long as you
get it back when you need it, _who cares_?

~~~
bo1024
The issue is just transparency. You want to know how much memory you actually
have available for use if you need it. How would you like it if your car's gas
gauge was close to empty all the time because the car was caching gas for long
trips?

It would seem there's a simple solution -- another number on the system
monitor displaying how much memory is available for use if needed.

~~~
jfb
Flawed analogy: you use up the gas and your car stops. You use up memory and …
the kernel swaps pages around. Now, if the kernel _isn't_ giving you back
memory, that's a problem, but the OP doesn't actually show that this is
happening.

~~~
bo1024
No, it captures what I want to worry about. I do not want to be in the
situation where processes that I am interacting with in real time are paging
stuff out to disk. This is really bad for my user experience.

So if my memory is "full" with a bunch of just-in-case stuff, I'll gladly swap
it out for real data that a real running process is using it. But if it's
"full" of data in use for running processes, then I want to think twice about
opening a new application. And I want my memory manager to tell me the
difference between those two "full" cases.

------
digid
I also have major memory problems. 8GB RAM total in the system and I have 4GB
sitting in inactive and it's paging out? <http://imgur.com/VE4GB> At this
point the system pretty much thrashes until I start closing apps or perform a
manual `purge`

~~~
chrisballinger
I have the same issue. This is unacceptable.

------
deweller
I had a similar problems with my Mac slowing down to a crawl with certain
instances of disk access.

I tried turning off spotlight (which was taking a very long time to complete)
but it did not help.

For me, the problem turned out to be a failing hard drive. After replacing my
system hard drive, things returned to normal speed.

I'm just posting this in case it might help someone else.

~~~
coffeedrinker
I concur. I've seen this exact behavior on two different systems when the hard
drive was beginning to fail. Swapping the drive fixed the problem.

My friend had installed a new larger drive that was causing the problem,
whereas there were no beach balls while booting off the original drive via
USB.

------
illicium
There's a nice script[1] for tweaking OS X's dynamic pager settings to reduce
the system's swappiness that helps a bit. Incidentally, if you have both an
SSD and HDD installed, you can use it to move the swapfiles to the HDD to
reduce wear.

[1]: <http://dropsafe.crypticide.com/article/3848>

~~~
fanf2
Have they not improved the dynamic pager parameters in the last two years?

------
kfury
Thank god for this article. My wife is a photographer making heavy use of
Lightroom on her 17" MBP and has been experiencing these exact problems for a
year or two. We've tried everything to fix it, rebuilding the system from
scratch, to no avail.

She had 4 gigs of RAM which we recently upped to 8gigs which reduced the
severity of the problem.

I really, really hope this is something that gets fixed in Mountain Lion.
Tasks that should take 20 seconds take 10 minutes or more.

It's good to know she's not crazy.

~~~
nirvana
She's not crazy, but she is running Adobe software on a machine without
sufficient RAM. Adobe installs gods own cache of really crappy stuff that
starts up at boot and who knows what kind of kexts they shove in there to make
your machine unstable.

I won't run any adobe software after I saw the abuse they did to my machine.

Apple basically gets a free pass if you're running Adobe. This is a company
that ships crap.

Also, you're probably starving it of sufficient memory. If Lightroom is up,
you're probably out of memory, even with 8GB.

I'd recommend getting rid of Lightroom and going to Aperture, or given
aperture is a bit behind the curve, upgrading to 16GB of RAM and seeing what
adobe-installed processes and KEXTS you can get rid of.

~~~
kfury
Moving from Lightroom to Aperture's not a possibility, given the workflow,
experience, and catalog data she's built up in Lightroom over the years.

Upgrading from 4 to 8 gigs last week helped a lot. I'd go to 16 except her MBP
won't support it.

I'd love to get her on an SSD but she's on a 1tb drive now and it would be
hard for her to try and fit into a 512gb SSD now (especially now that she's on
the D800 with huge video files and 72mb raw photo files.

It's frustrating that it will work find some of the time and not others,
implying that the problem could be fixed with better memory management. I do
hope that a serious Adobe competitor arises to force Adobe to make its apps
faster and more resource efficient.

~~~
batista
_> Moving from Lightroom to Aperture's not a possibility, given the workflow,
experience, and catalog data she's built up in Lightroom over the years._

Forget the advice. Lightroom _is_ faster, as noted in every review of both
programs. Try Aperture yourself with the demo to find out.

Working with 10+ megapixel images is always going to be slow, and with camera
advances, it will get worse every time your wife gets a higher resolution
camera --so comparing it with how it used to be when you have 6mp files is not
exactly correct.

More memory and an SSD will definitely help.

------
KC8ZKF
It occurs to me that HFS might be the real culprit. A lot of the bad behaviors
described here involve heavy disk use. John Siracusa has a nice round-up of
all the HFS faults:

[http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.a...](http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.ars/12)

------
collint
You can run `purge` in a terminal to free your 'inactive' ram.

I've set up a cron job to purge frequently, keeps thing humming.

~~~
sabat
Cmd line syntax, for the lazy, please?

~~~
fromhet
I made a bash script for it and I'll share it, hacker 2 hacker. Goes a little
something like this:

#!/bin/bash

purge

~~~
cpeterso
What license are you releasing your software under?

~~~
fromhet
Proprietary, nanananana

------
chrisdroukas
Does anyone else notice extreme time-based slowdowns using multiple monitors?
I've looked through forums and system logs and I can't find an immediate
explanation for it. The system tends to hang when using multiple monitors for
any extended period of time.

~~~
yeureka
Yes, ever since Lion I need to use the 9600m in my MBP instead of relying on
the cooler running and less power hungry 9400m. Never noticed the ram problem,
but there are other issues with Lion that I never encountered with Snow
Leopard. For instance, sleep seems to take forever now and I can't use my
external monitor without the fridge magnet hack. I might get downvoted for
this, but my MBP seems faster and runs better on Windows 7 than on Lion at the
moment. I hope ML improves the experience.

------
wagerlabs
[http://wagerlabs.com/blog/2008/03/04/hacking-the-mac-osx-
uni...](http://wagerlabs.com/blog/2008/03/04/hacking-the-mac-osx-unified-
buffer-cache/)

It's called the Unified Buffer Cache (UBC).

------
munin
the OS X kernel is open source. so why aren't people reading it to figure out
where this bug is?

~~~
kevingadd
Yeah, I'm sure if you just read the Darwin kernel there's a '#define
USE_LOTS_OF_MEMORY 1' in there that you can change.

The class of problems described in the original post are not the sort of thing
you 'just find' by glancing at kernel source code. The problems described
sound like they could be an issue of poorly tuned heuristics/thresholds, or
necessitate some extra machinery inside the OS X memory manager that isn't
there currently. It's not like you can send Apple a pull request on github.

~~~
munin
yes I know, that's the point of my question ;)

everyone is all positive about "open source" until they have to dive into a
few millions lines of complicated system-level C code and then...

~~~
RickHull
> yes I know, that's the point of my question ;)

It's a facile point.

> everyone is all positive about "open source" until they have to dive into a
> few millions lines of complicated system-level C code and then...

Does anyone doubt that 99% of open source users never read a line of the
source code which they are using? The point is, they have the opportunity to,
and more importantly, the 1% (or whatever) with the skills and resources are
able to actually do something about it.

If you don't have the ability to change or examine the source code, then there
is little incentive to do any runtime analysis which might illuminate the
problem.

------
United857
I've gotten a lot of his symptoms, and there might be another cause:

<http://reviews.cnet.com/8301-13727_7-20064489-263.html>

Bad blocks in the disk, causing the system to beachball frequently due to disk
I/O failures when swapping out to disk.

The solution for me was to back up, reformat the disk and zero-ing out
everything causing bad sectors to get remapped, and then restore.

~~~
DavidAbrams
I have to say, I was experiencing a shitload of disk thrashing on my iMac, and
eventually decided to replace the drive. So I did the whole ridiculous
suction-cup routine (yeah, that's Apple "elegance") and replaced the drive.

Problem resolved. Not that I don't still get inexplicable pinwheels, but
nothing like before.

------
lattepiu
Something is quite wrong indeed. I disabled the dynamic pager, and now my
system is working as it's supposed to. Snappy and responsive.

I opened all of my apps, expecting it to crash miserably: instead, the system
started paging as it should, stayed responsive (though slower), and promptly
returned to normal once it regained memory.

I don't know what's going on, but I can definitely say that this is how I want
my computer to work.

------
herf
I think this is the penalty we pay for the advice from two years ago:

"Buy all your developers SSDs. It makes them more productive."

------
waivej
Try "Free Memory"... I looked for a solution to this problem a few months ago.
My computer runs better if I free the memory every few days. For example,
resuming a parallels virtual machine drops from 30 seconds down to 3-4. Note,
this is a 4GB Core 2 Duo with SSD.

------
kirbysayshi
My completely non-scientific observations have found that OS X needs plenty of
RAM, like any modern OS. However, any disk I/O task has a huge performance
impact on the rest of the system, as described by this article. For example,
something like unRARing a file will affect the entire system detrimentally,
even if CPU usage is nominal. By affect I mean even the cursor can get
jittery, which is normally unheard of on OS X.

This typically affects me in low memory situations, such as less than 100mb of
free memory. The effect is most pronounced when switching between browser
tabs, which would cause a lot of disk usage... pulling all of that data in and
out of non-ram cache.

------
daemeh
I don't have any tests to prove this, but switching from a 64-bit kernel to a
32-bit one and forcing apps to run in 32-bit mode helps a lot with memory
usage on OS X. You can use this app to switch apps to 32-bit:
<http://www.macupdate.com/app/mac/40405/sixtyfour>

If you look at Windows 7 memory consumption with the same set of software you
use in OS X, you'll notice memory usage is 1/2 or 1/3 on Windows compared to
OS X. Maybe someone knows why that is?

------
marcamillion
Anyone have any nice articles with tips on how to generally optimize OS X? Esp
to better handle this paging/memory management problem that the OP is talking
about.

I have a MBP with 4GB RAM and leave programs open all the time. After a few
days, it feels very sluggish.

Aside from double my memory and changing my habits (i.e. shutting down every
night), how do I fix this?

------
DanI-S
I'm (fairly) uninformed on this, but from an initial read of the post it seems
like memory management may have been optimized for SSD-equipped systems, at
the expense of hard disk performance?

Whether this is unintentional, part of a calculated tradeoff, or a cynical
business/tactical decision is another thing.

~~~
nirvana
1.5TB of spinning rust in my macbook pro, no observations of this problem. Did
see something like it when I was using an SSD that was about to fail.

------
hmart
The only winners are those "Mac cleaner, keeper" apps whose Google Ads know we
are all watching beach balls.

~~~
puredanger
Apple should really sell ad space on those beach balls.

~~~
joeyh
Ah, so it's some kind of hourglass/throbber display. As a linux user with a
whopping 1 gb of ram on my laptop, I was puzzled by what that term meant. :)

------
adityanag
Damm.. I turned swap off, and now I have 3 VMs running concurrently on my 2009
MBP with 8 GB RAM, and it's smooth! Before this, even one VM would cause the
system to periodically become unresponsive. Ok, this is my _subjective_
opinion, and you can ignore it, but hey, it works for me.

------
rdg
I fucking hate OS X Lion Vista. I really miss the stability of Snow Leopard.
But can't easily go back.

------
jguimont
When time machine starts on my MBA ( to an external hd ) it almost freezes the
Mac. Is this related?

------
rangibaby
Disabling dynamic paging as suggested in the fine article seems to have made
some apps that constantly gave spinning wheels before (Firefox, Time Machine
backups) some extra speed.

However, it's still early days. It might just be a "washed car effect."

(Mac Pro 1,1 / 7GB RAM / WD Caviar Black)

------
jhspaybar
I too have noticed huge issues particularly when using photoshop or final cut
pro. I figured it was the applications, but if it's the OS that's definitely a
much bigger issue. I regularly restart every 2-3 hours when using those two
programs heavily.

~~~
nirvana
In your case, it is the applications. Final Cut Pro X still has some
instability, and photoshop is crap.

~~~
some1else
If Photoshop is considered crap, the rest of Adobe software is coded by
blindfolded bongo-drum players.

------
hollerith
Interesting tangent: Plan 9 never had "dynamic paging" (swapping to disk). It
supports virtual memory, but not swap. This information is accurate as of
about 6 years ago (when I stopped following Plan 9).

------
comex
Anyone have a radar number? This entire discussion is incredibly vague.

------
jmah
I've had problems with mtmd (Mobile Time Machine) really slowing down writes
(and all disk stuff) since the Lion pre-releases. With that off (sudo tmutil
disablelocal) things are pretty smooth.

------
kghose
Awesome. The thread is more informative and entertaining than the article!
This is Hacker News!

------
forgetcolor
i don't understand why anyone who cares about performance doesn't at least max
out the RAM, let alone use an SSD as their boot disk. sure, the SSD is
expensive, but the RAM? dirt cheap. i only wish the MBP could take more.

------
gulbrandr
Please:

font-size: 16px; line-height: 1.5em;

------
carguy1983
I have an 8-way Xeon Mac Pro w/ 20GB of RAM, almost half of which is 'free' at
any point during the day unless I'm doing something really out of the
ordinary.

Yet it still swaps to disk ALL THE TIME and a new Terminal.app window can take
up to 5 seconds to open.

I really don't give a shit how it's not "technically" broken - that's broken
from an experience point of view. And I haven't re-installed the OS (this was
an App Store upgrade from Snow leopard) because that's a major pain in the ass
as this is an actual workstation used to do actual work.

I can't believe this is actually advice, either - that's what Windows users
used to say in the 90s. Anyway, I guess I'm just ranting. OS X is wonderful
except for the fact that it sucks at managing memory to keep a system snappy.

~~~
thought_alarm
_Yet it still swaps to disk ALL THE TIME and a new Terminal.app window can
take up to 5 seconds to open._

That's not swapping. That delay is /usr/bin/login searching the system logs so
that it can display the date and time of your last login.

Create a .hushlogin file in your home directory to prevent that.

~~~
saurik
No. The sequence of events concerning this in login:

0) `login -pf`

1) quietlog = 0

2) if ("-q" in argv) quietlog = 1

3) if (!quietlog) getlastlogxbyname(&lastlog)

4) if (!quietlog) quietlog = access(".hushlogin") == 0

5) dolastlog(quietlog) ->

6) if (!quietlog) printf(lastlog)

You can see from this that the "searching the system logs" (which, to be
clear, is going to be really really fast: /var/run/utmpx is a small file with
fixed length fields) happens in step #3, before .hushlogin is checked in step
#4.

If you wish to verify, you can read the code at the following URL. Note that
__APPLE__ and USE_PAM are defined for the OS X distribution of this code,
while LOGIN_CAP is not.

[http://opensource.apple.com/source/system_cmds/system_cmds-5...](http://opensource.apple.com/source/system_cmds/system_cmds-541/login.tproj/login.c)

~~~
thought_alarm
It does not use /var/run/utmpx anymore.

Look at the code for getlastlogxbyname(). It does an ASL query for last login,
and that's the source of the delay.

[http://www.opensource.apple.com/source/Libc/Libc-763.12/gen/...](http://www.opensource.apple.com/source/Libc/Libc-763.12/gen/utmpx-
darwin.c)

~~~
saurik
As I stated, that cannot be the source of the delay, because getlastlogxbyname
is called based on a check of quietlog before quietlog is updated to take into
account .hushlogin. With the exception of step #7, all of this code is inside
of a single function (main), which makes it very easy to verify that the
sequence of events I'm describing is correct. (I will happily believe you,
however, that getlastlogxbyname is internally now using something horrendously
slow to look up that information.)

(edit: I have gone ahead and verified your statements regarding
getlastlogxbyname now being based on ASL. Using that knowledge, and based on
st3fan's comments about the output of dtrace, I then used dtruss to verify my
own assertion regarding the order of events. The result: .hushlogin in fact
only affects the output of "last login"; it does not keep login from getting
that information in the first place with ASL. To keep it from doing so you
must pass -q, something Terminal does not do.)

~~~
thought_alarm
You're right. ASL is the source of the slowdown, but .hushlogin isn't actually
doing anything to solve the problem.

The correct way to bypass the ASL query is to set Terminal to open shells with
/bin/bash (or your shell of choice) instead of the default login shell.
Terminal will still use /usr/bin/login to launch the shell, but it passes the
-q switch to prevent the ASL query.

When I dug into the source code a couple of months ago, I inadvertently made
both changes (Terminal settings and .hushlogin). Clearly it's the Terminal
settings that solved the problem and not .hushlogin. Thanks for clearing it
up.

------
nirvana
This claimed problem is not adequately described-- because I don't see it.
Therefore there is something else going on here.

I have 8 GB of memory on my Macbook Pro, and I've never seen anything like the
problems described in this article. I leave my machine up for weeks at a time,
I leave the Time Machine drive connected for weeks, and never have a slowdown,
even when time machine is backing up.

The only time I have memory issues is when I have too many safari tabs open
for too long. Eventually safari takes too much memory. So, I shut down safari
and start it back up-- it opens up all the tabs that were open and takes a lot
less memory.

I'm kinda astounded that people with 20 and 32GB of RAM and 8 CPUS are saying
it takes 5 seconds to open a terminal window. Have never seen anything like
that.

I would venture to guess that these people who are seeing the problem are
running a kernel extension or possibly have otherwise modified their machine.

~~~
9oliYQjP
Running your setup and I've seen this problem only with VMWare Fusion running.
But they have KB article
([http://kb.vmware.com/selfservice/microsites/search.do?langua...](http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1038864))
which discusses what they're doing. VMWare Fusion won't let go of memory
allocated to a _suspended_ VM, only to a VM which has been fully shut down.
The rationale is that the user might unsuspend the VM so it's a performance
tweak. But I never use my VMs this way, so I've resorted to shutting down my
VMs and everything is back to being snappy.

------
algoshift
> OS X is wonderful

ROFL

~~~
algoshift
I guess the point of the short comment was lost: How can anyone say that any
of the current crop of OS's is "wonderful"? Wonderful? Really?

Whether you use Windows or OSX (or both, as is my case) you can probably
rattle off a sizable list of how these OS's have gotten screwed-up by their
respective publishers. Someone saying "<OS name> is wonderful" and then going
on about the reason it actually isn't is very funny.

Again, the comment was OS agnostic even though the thread is about OSX.

