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 ?
Something is deeply broken in OS X memory management
201–210 of 269 posts
Re: Something is deeply broken in OS X memory management
#202Earlier 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
#203Earlier 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.
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
#204Earlier 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/
Re: Something is deeply broken in OS X memory management
#205I 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.
Re: Something is deeply broken in OS X memory management
#206Earlier 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…
Re: Something is deeply broken in OS X memory management
#207I 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.
Re: Something is deeply broken in OS X memory management
#208Re: Something is deeply broken in OS X memory management
#209I 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.
Re: Something is deeply broken in OS X memory management
#210Earlier 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.