Live data from Hacker News

Something is deeply broken in OS X memory management

workstuff.tumblr.com

201–210 of 269 posts

Re: Something is deeply broken in OS X memory management

#201
post #37

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.

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 ?

He is not talking about disk cache, disk cache is accounted for separately, he's talking about actual memory being allocated by the kernel_task process. It's been obvious since Lion came out that there's a problem, and so far Apple hasn't fixed it.

Re: Something is deeply broken in OS X memory management

#202
post #79
post #37

Earlier quoted context omitted.

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 ?

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.

               total       used       free     shared    buffers     cached
  Mem:       2042520    1816496     226024          0     294344     486908
  -/+ buffers/cache:    1035244    1007276
  Swap:      4194300       8172    4186128
I don't know what you are using to view your memory usage, but any decent tool should give you at least the information that `free` does (see above).

Re: Something is deeply broken in OS X memory management

#203
post #85
post #79

Earlier quoted context omitted.

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.

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.

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.

Re: Something is deeply broken in OS X memory management

#204
post #170

Earlier 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.

If you are interested what happens when you open a new terminal window, run 'sudo opensnoop' in one window and then open a new window. Here the majority of files being opened are in /var/log or Homebrew related. Also interesting ... creating a .hushlogin did not change much. It still opens about 50 files in /var/log/asl/

Awesome! Thanks for pointing out opensnoop!

Re: Something is deeply broken in OS X memory management

#205

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.

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

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

Re: Something is deeply broken in OS X memory management

#206

Earlier quoted context omitted.

> It's like the system discards pages of programs just because the app has been inactive for an hour or so. From what I've read, Windows memory manager does the same thing - after a while, it swaps out unused pages, even if plenty of free memory is available. I wonder what's the logic behind this - did the engineers assume that the speedup coming from more free memory being available for disk cache is worth the hassl…

The logic is for things like daemons or infrequently used processes that wake up maybe once a day. They don't need to be in ram all the time needlessly. So swapping out their memory that hasn't been used for N hours isn't a bad thing. And yes, the logic is sound, its better to use a bit of swap for an infrequent daemon and let 4-5 megs of memory be at the ready if needed than leave it in place all the time. The "spee…

So why not lazy page? Swap to disk, but don't unlink the memory until it's needed by another process. If the paged app comes back to like first, it's still in memory and the paged copy on disk can be dropped.

Re: Something is deeply broken in OS X memory management

#207

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.

Thanks for this. I love learning something simple, new, useful, and that I probably should have already known after decades writing software.

Re: Something is deeply broken in OS X memory management

#209

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'd send you a dollar if I could for this post. Awesome.

Re: Something is deeply broken in OS X memory management

#210

Earlier quoted context omitted.

When the logs are read once, they should stay in the VFS cache as long as there is enough RAM, shouldn't they? Anyway, instead of running /usr/bin/login, I just use /bin/zsh as my Terminal.app startup command which is much faster. However, every time I access the file system, even some tab for autocompletion, it takes a few seconds. Even cd'ing into some directory can sometimes take a few seconds. Sometimes ~= it's m…

Changing directory is instant for me. (no SSD here, all spinning rust.) Tab completion is instant too. Run Time Machine every hour, never made a change to the spotlight config.

anything that hits the disk heavily, including time machine, kills my snow leopard machine. lack of ui responsiveness, beachballs et al.
Post reply on HN