Live data from Hacker News

Something is deeply broken in OS X memory management

workstuff.tumblr.com

111–120 of 269 posts

Re: Something is deeply broken in OS X memory management

#111
post #92
post #2

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.

That's a terrible idea. `purge` is not a tool for freeing inactive ram. It's a tool for deleting the filesystem cache in order to simulate cold boot conditions for performance analysis. Yes, it has the side effect of reducing memory usage, inasmuch as it's throwing away stuff that was kept in memory. But that doesn't make it an appropriate tool to use.

What's the downside? It worked for him.

Re: Something is deeply broken in OS X memory management

#112

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…

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.

I know I shouldn't say it (a dozen have already done so), but thank you. Just wonderful. My terminal just got 10 times better. I'd make it 'best comment of the month' if I could.

Re: Something is deeply broken in OS X memory management

#113
post #4

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…

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…

Two things I have found to help the most to improve everyday usage on OSX Lion without an SSD: 1. Disable Spotlight on the boot volume. This keeps the mds process from reindexing things so frequently. 2. Use Time Machine Scheduler (free utility) to backup at 5am or something so it's not interfering with daytime tasks.

Re: Something is deeply broken in OS X memory management

#114
post #111
post #92

Earlier quoted context omitted.

That's a terrible idea. `purge` is not a tool for freeing inactive ram. It's a tool for deleting the filesystem cache in order to simulate cold boot conditions for performance analysis. Yes, it has the side effect of reducing memory usage, inasmuch as it's throwing away stuff that was kept in memory. But that doesn't make it an appropriate tool to use.

What's the downside? It worked for him.

Yeah, I've had zero problems doing this for over a year. I used to get into swap hell every other day and now my life is beautiful and awesome.

Re: Something is deeply broken in OS X memory management

#115

Earlier quoted context omitted.

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.

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.

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.

Re: Something is deeply broken in OS X memory management

#116
post #84
post #24

Earlier quoted context omitted.

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. I think you missed a key ingredient to this problem, which is heavy disk reads caused by either spotlight or time machine. Reading a massive amount of data (that you'll probably not use again anytime soon) has the unfortun…

Isn't this what POSIX_FADV_DONTNEED is for? http://linux.die.net/man/2/posix_fadvise

[deleted]

Re: Something is deeply broken in OS X memory management

#117
post #55

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_N…

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

Re: Something is deeply broken in OS X memory management

#118

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…

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.

Two other things that can make OSX terminal launching slow:

1. The default use of /usr/libexec/path_helper to manage your $PATH.[1]

2. An accumulation of log files in /var/log/asl.[2]

For (1), I just edit /etc/profile and disable path_helper altogether. I set the PATH manually. (This also allows me to put /usr/local/bin before /usr/bin, which is my preference. I've never understood Apple's default settings for $PATH. They put /usr/local/bin later - which defeats the whole point of installing, say, a newer vim in there.) For (2), a cron or launchd job can take care of it.

[1]: http://mjtsai.com/blog/2009/04/01/slow-opening-terminal-wind...

[2]: http://osxdaily.com/2010/05/06/speed-up-a-slow-terminal-by-c...

Re: Something is deeply broken in OS X memory management

#119

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…

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.

Doesn't OSX rotate logs? Seems weird that it should take so long.

Re: Something is deeply broken in OS X memory management

#120
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.
Post reply on HN