http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.a...
Something is deeply broken in OS X memory management
221–230 of 269 posts
Re: Something is deeply broken in OS X memory management
#222I 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…
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.
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...
Re: Something is deeply broken in OS X memory management
#223I 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 foot…
exFAT is Microsoft proprietary shit.
Re: Something is deeply broken in OS X memory management
#224Earlier quoted context omitted.
What are you gonna do about it when you find and fix the bug? You can't run a custom kernel on OS X.
Yes you can: http://shantonu.blogspot.com http://objc.id.au/post/10101528120/compiling-the-os-x-10-7-k...
Re: Something is deeply broken in OS X memory management
#225Earlier quoted context omitted.
> The thing is, Lion runs like crap without an SSD or insane amounts of RAM for many people. YES. I have a MacBook Pro Core i7 from a little while back with an old style spinning rust drive and a 11" MacBook Air Core 2 Duo. For purely CPU bound things, sure, the Core i7 kicks the pants out of the Core 2. Same for videogames. For day to day use, though, switching between Eclipse, Xcode, Chrome, etc. the Air provides a…
Why don't you spend $140 and add an SSD to the pro? You can keep the HDD for an extra $80 with a cd drive bay HDD caddy.
Left some big files on the old HD, and symlinked them. The disk stays idle in the CD bay until I need it, then spins up.
Re: Something is deeply broken in OS X memory management
#226"Buy all your developers SSDs. It makes them more productive."
Re: Something is deeply broken in OS X memory management
#227Earlier quoted context omitted.
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.
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…
Re: Something is deeply broken in OS X memory management
#228Earlier quoted context omitted.
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…
But why does .hushlogin makes Terminal.app come alive faster?
However, assuming that is the case for some people, we have to look elsewhere than the last login lookup. There are only a few other usages of quietlog: motd (open file, read it), mail (check environment, stat file), and pam_silent.
The first two are not going to cause any kind of performance issue, so we have to look at pam_silent. This variable is particularly interesting, as it is only set to 0 if -q is not passed (and it is not) and there is no .hushlogin (it is not directly controlled by quietlog).
If it is not 0, then it is left at a default value, which is PAM_SILENT, and is passed to almost every single PAM function. It could very well be that there is some crazy-slow logic in PAM that is activated if you do not set PAM_SILENT.
Given this, someone experiencing this issue might look through the code for PAM to see if anything looks juicy (and this is something that will best be done by someone with this problem, as it could be that they have some shared trait, such as "is using LDAP authentication").
(edit: FWIW, I looked through OpenPAM, and I am not certain I see any actual checks against PAM_SILENT at all; the only mentions of it are for parameter verification: the library makes certain you don't pass unknown flag bits to anything.)
Re: Something is deeply broken in OS X memory management
#229Earlier quoted context omitted.
> The thing is, Lion runs like crap without an SSD or insane amounts of RAM for many people. YES. I have a MacBook Pro Core i7 from a little while back with an old style spinning rust drive and a 11" MacBook Air Core 2 Duo. For purely CPU bound things, sure, the Core i7 kicks the pants out of the Core 2. Same for videogames. For day to day use, though, switching between Eclipse, Xcode, Chrome, etc. the Air provides a…
Why don't you spend $140 and add an SSD to the pro? You can keep the HDD for an extra $80 with a cd drive bay HDD caddy.
It also turns out I rather like working on an 11" screen. Keeps me focussed.
Re: Something is deeply broken in OS X memory management
#230Earlier quoted context omitted.
"It's definitely getting slower but that's expected since it's such an old system." I see this sentiment a lot, but I disagree with it. What are "iTunes, Xcode, Safari/Chrome, and a mail client" doing now that they weren't doing four years ago? Is it enough to justify their latest versions feeling less responsive than their versions from four years ago?
Safari/Chrome: websites are more complex, more image-heavy, and more JavaScript-heavy iTunes: layers of software for dealing with Wi-Fi sync, Ping social network, iTunes Match, and so on Mail Client: totally agree with you there... But I still pretty much agree with you overall...
Things change. My old 2006 iMac core 2 duo feels a bit clunky sometimes these days, but it runs a lot of stuff fine and is actually just as good a machine as it ever was.