141–150 of 269 posts
Earlier quoted context omitted.
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.
Doesn't the latter void warranty?
Earlier quoted context omitted.
>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 I read through the comment of a few weeks ago, and I did not see anything conclusive or even anything that would outweigh my subjective impressions that something about Lion on my (stock) 2011 Mac mini is causing unnecessary lack of responsiveness. You might be uncomfo…
Do you have a link? I tried to search hn but, alas, in vain.
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.
Hard drives can read read data sequentially very, very quickly. On whatever generic SATA hard drive I have in my workstation, I get: eklitzke@gnut:~ $ time sudo head -c 1073741824 /dev/sda > /dev/null real 0m8.267s user 0m0.220s sys 0m0.810s So I can read 1G off the drive in about 8 seconds. Even if the login command does need to sequentially read through logs to find the last login time (and I'm skeptical of that, b…
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.
Caches exist for a reason. Deleting them willy-nilly tends to be a bad idea.
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…
People say "Get and SSD", well, I've had 2 SSDs and 4 SSD failures (one drive failed three times, the other once and its replacement is still going.)
So, I'm all spinning rust here. 1.5 Terabytes of rust in my Macbook Pro and the only time I have a beach ball is trying to launch Team Fortress (but I blame valve for that).
I have massive, MASSIVE Final Cut and Aperture libraries. I leave the machine up for weeks. I leave Time Machine running all the time- there isn't even a slowdown when time machine is backing up.
My hard drives are encrypted with full disk encryption which means not only am I running spinning rust but its encrypted rust which means every read has to be decrypted.
No slowdowns or beach balls. Sure the occasional poorly written program will have a beach ball, and rendering video takes awhile, but that's to be expected.
Yet people constantly say that Lion sucks? Really? And they have these more beefy machines with more RAM?
Something doesn't add up here.
ROFL
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.
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.
Earlier quoted context omitted.
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 ;).
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...
At my machine with 8 GB RAM and uptime of 4 days I have page outs of only 2 Megabyte. And page ins of 2 Gigabyte.
P.S. I subscribe to your blog! * starstruck
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.…
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.
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.