I have a brand new 2013 model MBP (Retina display, 16GB RAM, Apple SSD) running Mountain Lion. I actually upgraded because my 2011 model was getting these freezes, and I assumed it was a hardware problem.
But my new MBP has been sluggish from day one. That is, from the moment I migrated my user files from my old box. It's possible that I got some stuff that affects performance. Three things helped:
* First, disabling the dynamic pager [1]. This one has a dramatic effect on performance. In theory, it will prevent OS X from swapping out apps unnecessarily (which it will do even when the apps are active and there is plenty of RAM). I did have some, but not much, swapping going on, but it still improved performance.
* Secondly, I uninstalled iStat Menus. I can't be sure that this contributed to the performance problems, but I won't risk reinstalling to find out. It seems to have helped a bit.
* Thirdly, I disabled Spotlight indexing of my home directory. This way Alfred will still autocomplete apps. Some apps lose their search functionality, but I never use Spotlight, and I find that I can live without it.
I tried the sandbox config fix, but it made no difference to me.
The remaining sluggishness seems to come from the graphics layer. For example, doing the Exposé "reveal all windows" command takes 3-4 seconds on my box and has a frame rate of approximately 1 fps. It's not great. I notice the reduced graphics performance when scrolling pages in Chrome, whereas Safari is smoother. I suspect this is Retina being a bit too ambitious compared to actual current graphics card performance.
As an aside, I believe OS X's I/O system has traditionally been its weak point, being a Mach-based hybrid-microkernel architecture. You can cause GUI scheduling problems by overloading the I/O system, and it's possible that this is exacerbated by having a SSD.
It's possible that I got some stuff that affects performance.
It's almost certain that migrating something from your old mac caused this. Clean installs of OS X do not have the problems you describe, even on the 13" rMBP's weak GPU.
Disabling dynamic_pager disables swap, and that's not a good idea on OS X. Any perceived difference in performance is likely placebo. Have you tried a blind test? Have a friend disable/enable swap and see if you can guess correctly. You might be surprised at the results.
Instead of risking the instability and performance degradation that is likely to occur when changing low-level OS settings, you should figure out what you migrated that's causing the issue. Do some science. If you create another account and log in, do the issues persist? What if you boot off the restore partition? Are there any specific errors in the system console? If you backup, erase, and install a clean OS X, do the issues persist? What if you copy your dotfiles over to this clean install? What if you copy your old ~/Library to it? Etcetera. Once you reproduce the problem, you can use time machine to restore to an unaffected version.
You might as well upgrade from Windows XP to Windows 7, hack a bunch of registry entries to change kernel behavior, and then complain that Windows is buggy and slow. Blaming the operating system is easy, but it won't fix your problem. The cause is something you copied from your previous set-up. Find it and you'll be a much happier camper.
> but I'm guessing it's similar to this blog post from a while back
That's the link. He didn't change his mind, he merely upgraded and got better performance. That did not happen in my case.
> Have you tried a blind test?
No need. Before the change, my mouse pointer was freezing up every few seconds, and I got "IOHIDSystem cursor update overdue. Resending." in the system log very frequently. This disappeared completely after disabling the pager.
The difference in performance is stunning. For example, previously, opening a new tab in Chrome would not animate the tab line correctly, resulting in a weird "jolt" as the tab came into place. Now it's smooth.
> Do some science.
The problem is that these things take a lot of time. Time that I don't have. At some point I might create a new user and see if that helps.
>No need. Before the change, my mouse pointer was freezing up every few seconds, and I got "IOHIDSystem cursor update overdue. Resending." in the system log very frequently. This disappeared completely after disabling the pager.
The difference in performance is stunning. For example, previously, opening a new tab in Chrome would not animate the tab line correctly, resulting in a weird "jolt" as the tab came into place. Now it's smooth.
Both sound like problems TOTALLY unrelated to the dynamic paging, that accidentally were solved by disabling it. Especially seeing that people with the paging enabled don't see any slowdowns such as these AT ALL.
My guess is some BS software left over from the previous installation, a SIBML plugin, a haxie, or something else faulty, that caused the unnecessary paging. If you have found and removed that, then you wouldn't have had other issues with the paging functionality.
For what it's worth, I tried re-enabling the pager, and a few hours later the IOHIDSystem cursor update overdue error started coming back around twice a minute, keyboard input speed started suffering from micro-freezes, and apps such as Chrome started lagging again.
Parent is correct, and it's not placebo. Disabling swap on OS X usually results in a dramatic improvement. People unfamiliar with the poor memory management of OS X tend to become personally offended by this suggestion and often start explaining how swap works (usually incorrectly). The reason is simple; it swaps when it doesn't need to, and swapping is much slower than accessing memory. For what it's worth, I've been running this way for years.
Yes, I know how swap works - I'm a kernel developer (mainly FreeBSD, but I have experience with most mainstream desktop kernels, including Windows). No, it's not dangerous to run without it in 2013 if you have enough memory.
It must be something else going on. The Expose features should not be nearly that slow. My mid - 2010 Macbook with wayyyyy too many applications installed is still butter smooth on most animations.
When you are trying to push 100% more pixels with only around 20% more GPU grunt, you're going to have lag.
I have a feeling that the animations would be a lot smoother (and battery life a lot shorter) if the GP forced their laptop to use the dedicated graphics card.
Isn't it 400% more pixels. Retina should be 2x the width and 2x the height.
Anyway. Mine is slow too. With the nvidia card everything is mostly fine, with the integrated intel card everything is mostly sluggish.
There was a review of the 13" retina when it came out saying that the intel gpu was terrible and that he sent the laptop back and was going to wait for the next generation.
Well, for me it isn’t and I also have a rMBP. I believe you, it’s just that you are likely looking at a software issue. (No doubt that this software issue is likely exacerbated by the requirements of the screen and it sucks either way, but in principle the graphics hardware is up to the task.)
If I close Chrome, Sublime Text and Terminal it gets close to normal speed. Exposé seems to scale very badly with the number of apps running. It's also possible that some of these apps are badly optimized redrawing themselves in some way that slows down Exposé.
With 16GB RAM it's a non-issue at the moment. But it will be interesting to find out what exactly happens. Kernel panic? Does the app that can't allocate crash, but everything else works? Does everything just start to crash randomly?
Per your graphics issues, try installing gfxCardStatus[1] and watch for if/when it switches between integrated and discreet. I've found the integrated Intel graphics to be slow for OS GUI stuff like "reveal all windows" but discreet video is fine.
It will also let you choose which GPU to use which is useful for testing.
This whole thread is making me very pleased I didn't buy a Macbook Pro.
It isn't the fact that stuff goes wrong that bugs me, it is the fact that seemingly both the problems and solutions are via "magic." Even people who claim to be very UNIX knowledgable have no idea what is going wrong...
When Apple's stuff works it "just works." When Apple's stuff stops working then you're SOL.
In my experience, this kind of thing is no different than any other system I've used over the years. Windows, Linux, OS X -- all of them end up with odd problems that require a bit of digging around the web to sort out. Singling out OS X as "then you're SOL" seems like FUD to me.
When you have a problem in Linux, it may require some searching, but the solution usually makes sense at some level. Unless you're doing something very strange or bleeding edge, it's more likely that what you find won't be totally incomprehensible or inexplicable.
As for Windows... just restart it, you'll be fine. ;)
It only makes sense because you understand Linux. Windows is a black book to me, but I've worked with Windows hackers who had the same intuitive understanding of how their system worked as the neckebeardiest BSD hacker has of theirs.
I don't find this latest OS X buglet to be difficult to understand, but then, I've been using OS X for ages.
Are you suggesting Linux problems are easier to fix because you can read the source code to the kernel?
I'm sure on some level that's true, as you have the option to learn how, say, your WiFi drivers operate to decipher why your signal drops to three bars every 20 minutes.
However, in Windows, I generally know where to find configuration info: In one of three registry hives, which follow a pretty easy to parse tree structure.
In Linux, I'm totally lost finding where to configure different pieces of software. Each distro puts their various configs in different spots. Some in /etc/local/whatever, /etc/whatever/, /usr/share/local/whatever.d/, /opt/whatever/, /etc/opt/whatever.conf/, /usr/local/share/whatever.d/ and so on. Some times there are duplicates, which one is the correct one? How do I know? And on top of this, every config file uses different formats.
Wat? OSX is an open source OS (at the kernel level and more) but its UI isn't. Also, are you actually implying that you would've downloaded the Gentoo source, sifted through the source until you found the file with the bug, then debugged the compiled binary to see what exactly is happening? Yeah, I totally download all of Android's source when my app crashes.
Graphics drivers aren't open source either. A very large amount of actual Mac OS X performance problems and crashes come from the combination of the graphics drivers and CoreGraphics/Aqua. Both of these systems can use main memory and therefore might be influencing or be influenced by paging issues.
If you can get a reproducible case and capture enough useful diagnostic information you can give that to Apple to try to get a fix in some future version of OS X. Have a look at /usr/bin/sysdiagnose and /usr/sbin/spindump among other tools. I'm sure there are more diagnostic tools internal to Apple, which would require that you have a case that is reproducible from a new OS X install rather than from a system with files copied over. If you can identify the one file from ~/Library or wherever that triggers it, then you can pass that along as the repro case.
In general people (like me) just don't have the time to hunt down every crash, hang, etc. we find when using a computer. So I can understand if one doesn't bother with capturing diagnostics and repro cases or with downloading Darwin or Android source to debug a crash. I can also understand where huge frustrated discussions like this one come from. But deep down there is an answer, and it likely is not from some huge corporate failing on Apple's part.
Obviously, there's a level of understanding that requires source access, but problems for which that level of access is necessary as few and far between. This problem, for instance, is not one of them. I highly doubt that most people who are using an OS for which they have source access are either interested in or capable of doing analysis at that level.
>When you have a problem in Linux, it may require some searching, but the solution usually makes sense at some level.
Well, since you used "usually" and "some level", the same exact thing holds for OS X.
If THIS particular one doesn't make sense, it's because nobody bothered explaining the mechanism yet -- which should be trivial if investigated.
Isn't it obvious that "safe mode" boot foregoes running some system stuff? That probably lets some script the chance to fix something (bad permissions?) that it couldn't fix when the full system, sandboxing, mdworker etc were running.
Usually true, but Linux hardware problems are another matter. If its FireWire based you just type random things from forum posts until something happens.
You really shouldn't write random things from internet in your terminal.
Maybe the hardware problems is for the stereotypical consumer isn't interested in Linux if you compare to Windows and Mac OSX. Different story on server-hardware/software though.
>This whole thread is making me very pleased I didn't buy a Macbook Pro. It isn't the fact that stuff goes wrong that bugs me, it is the fact that seemingly both the problems and solutions are via "magic." Even people who claim to be very UNIX knowledgable have no idea what is going wrong...
Sounds like rationalizing the non-purchase to me.
Nothing voodoo about how OS X works. Just that nobody bothered to investigate this problem further (and that OS X sandboxing a custom component, and a recent one at that, not some standard UNIX/POSIX functionality, so not everybody is familiar with it). My guess is that the safe-boot thing lets some maintenance scripts run uninhibited by restrictions set in other run levels, which fixes the md issue.
That said, md is just a normal unix process. If you cared enough to find this out, you can see what's going one with fs_usage, you have Dtrace available and other niceties etc.
In any case, nothing unlike the numerous problems people have with the intricacies of selinux.
To be fair, if you have a linux problem and Google leads you to Ubuntu forums, the solutions you will find there will likely be ugly strings of misunderstood magic too.
It's just a general fact that, given enough time and some trial and error, one can make problems go away even without understanding the root cause. I don't think it varies so much from one OS to another.
Is that a lisp config file? Blimey. Is this common in OSX land?
I'm somewhat skeptical that this will fix the random beachballing, because I'm pretty sure I've been seeing that since before ML. The fact that I put up with it is testimony to how badly windows and (desktop) linux suck.
EDIT: tried the config edit and rebooted, not seeing the "deny mach-lookup" error any more but I am still seeing regular "Unable to talk to lsboxd" messages. I guess I'll try the safemode thing later.
EDIT2: another thing I've done in my quest to banish the beachball is to uninstall iStat Menus. I'm sure there are many others here who use it. It was causing lots of crazy behaviour in the SystemUIServer process. Now I've binned it, things seem better. It's a shame, I liked those graphs. Anyone know another tool that can show me per-process bandwidth usage?
It seems to be an actual Lisp-1 dialect, not just Scheme-like syntax. In (Lion's version of) application.sb, there are a whole bunch of lambdas and letrecs flying around. They even define a macro.
Interesting, I never really dug too deep into it, aside from making a couple of changes and standard entitlement stuff for applications. application.sb looks like a complete nightmare to maintain.
Is it really that unrealistic in 2013 to expect my machine to be able to update a few graphs once every couple of seconds without falling to its knees and weeping? I know it's having to make lots of calls into the kernel to get the data, and I can live with it taking up a little bit of CPU now and then, but I have a right to expect it not to hang the OS.
I guess the ugly UI of the thing should have been a warning.
>Is it really that unrealistic in 2013 to expect my machine to be able to update a few graphs once every couple of seconds without falling to its knees and weeping?
It depends on how it's coded. And stat apps are notorious for using lots of resources.
Otherwise, a 2013 machine is a pretty tough beast performance wise, including running tons of highly demanding apps.
For people that know about DAWs, this video proves that the Retina MBP 15" is an absolute beast:
Ugly is probably too harsh, you're right. However I find that amount of fiddly extra chrome sets off alarm bells in my head. The config app gives me flashbacks of trying to delete norton utilities.
Yes. Same here. It freezes and while I can type a little, it ends up "liiiiiiik tttttiis".
Those freezes got a lot rarer after I disabled the dynamic pager [1]. I have only experienced it once since then.
I have had vm_stat and iostat running constantly to see if I can catch any metrics when it happens, but nothing stands out. It's not related to excessive I/O or swapping.
Yes, this happens to me too but only under certain circumstances.
It happens all the time if I have an external keyboard plugged in and try to use the built-in keyboard or trackpad. It will often be non-responsive to input for about 5 seconds. Once both the keyboard and trackpad completely stopped working and I had to reboot (using the attached external keyboard). I noticed some USB errors in console once when this happened but didn't investigate.
I've also seen this when it's asleep and I try to wake it up. Often it will take 5 sec or more to respond and wake up.
I'm seeing the same thing. This is my first real Mac experience, got it from/for work, wasn't sure if something like this was "normal". (I'm a long-time Linux user, so I'm used to putting up with a lot of bullshit from my desktop.)
I've found a handful of forum posts and support requests, but no solution other than "it's probably a hardware defect and you should return it".
Definitely. I also lose the keyboard at the same time too though, so it's potentially a USB issue as well. Doesn't happen frequently enough that I'm able to work out exactly what causes it.
I occasionally get into a state in ML where the mouse click events stop working (and the Cmd-Tab UI doesn't show up). This persists until I kill "Dock". Then the mouse starts working again (and the desktop resets itself), but the dock and Cmd-Tab UI don't come back. (Cmd-Tab works, but doesn't display the UI.) I never figured out the magic thing to kill to fix this, and end up rebooting.
(This hasn't recurred since the latest point release, so it may be fixed now.)
I began experiencing this problem on my mid-2008 MBP late last year. More recently, I've found that slipping a piece of paper between the battery and the golden electrical strip helps a lot.
I'm pretty handy with Unix but this problem and fix seem like pure magic. What problem with Spotlight indexing / Time Machine could cause the entire GUI to lock up in the first place? I'm used to random Apple apps like Finder and iTunes beachballing because they are badly written, but the whole OS?
The "alternative fix" hidden text at least explains why booting Safe Mode might magically fix things; it's "rebuilding things and clearing caches". What a mess.
I suppose so, but that's a pretty severe bug. The whole sandboxing system is pretty controversial in the first place, the idea that bugs in it are causing users' GUIs to lock up is pretty horrible.
Well, it's not like millions of users are in tears all around the country. I for one, have had no such problem. Bugs happen, anyway, it will be fixed in a subsequent update.
Can't safe boot with a Filevault 2 boot disk. Thanks, Apple!
You get to decrypt the disk, safe boot, verify fix, then re-encrypt the disk. Apparently the boot loader can't pass a boot variable down after the transfer or something? Anyone have insight here?
When designing a new system-wide architecture like a new storage subsystem, edge cases matter. A lot. I'd call it, at best, an oversight in the design phase of CS-WDE and, at worst, incompetence.
Why are you moving fsck_hfs around? I do notice if i'm booting into safe mode that fsck_hfs is taking FOREVER. (running 12 hours so far on my retina mbp 15, which is ludicrous)
But just switching to single user (aka boot-args="-s -v") and manually running fsck_hfs -c 4096m -f -d /dev/disk1 (or equivalent) I managed to clean up / of a few problems in under 4 minutes. fsck_hfs looks like it could use some fixing to dynamically cache things better, that or they could give it default arguments based on the systems memory size to speed things along.
Either way I'm done with trying to fix this, just going to reinstall 10.8.3 from scratch and rsync over my home directory and reinstall vmware. I've tried about every fix for the sandbox nonsense, and since this system had 10.7 originally maybe it upgraded badly, whatever.
Hmmm...I wonder if this is my roommate's problem. Last year I gave her my 2008 Macbook Pro (a fully decked-out one at the time) because her 8 year old iMac broke...and she has been complaining constantly about how slow it is. She incessantly curses out the beach ball and will slam the mouse down repeatedly because she swears it makes the ball go away faster.
Because of that last bit, I've never taken her seriously. That laptop was working fine when I was using it for Photoshopping raw images while having 15 browser windows open...her use-case is literally to have something to check GMail with and sometimes listen to her iTunes collection. I've gone into the laptop several times to make sure there isn't bloatware on it, and have disabled every extraneous feature...and yet she still has the few-second freezes issue (and I've been unable to reproduce it)....Hopefully this is the solution to both of our problems.
The beach ball is a different issue... this is basically a complete freeze where the mouse cursor doesn't move for a few seconds. Doesn't happen all that often, but it's quite annoying whenever it does happen.
Do you have an Java apps running in the background, such as a Java based backup tool? On my previous Macbook I had problems with it beachballing and it seemed to be caused by issues with Java.
I don't think it sounds like the same thing - though, if you find the solution to your roommate's issue I'd love to hear it.
I have a new (< 6 months) Mac Mini running ML and it's infuriatingly slow opening applications. It's not unusual to wait 10-15 seconds after clicking to open Chrome or Spotify (or anything else). My 5 year old MacBook does the same thing in a fraction of the time (running SL).
And one of those terrible clear plastic mighty mice with the useless trackball. I'm quite surprised it's lasted this long given the beating she's given it.
Same for my 2011 Air, I was thinking about formatting and re-installing OS X. Not sure I can reliably reproduce the few-second freeze in OS X, but it does happen (and is very noticeable when it occurs).
I didn't fully realize that I had this issue (I mean, I saw freezes, just assumed it was Photoshop or something causing it). Did the reboot fix and things seems to have worked. Whereas before mdworker errors were entering the console every 2-3 minutes, it's been 30 since I did the reboot and haven't seen an mdworker error since.
I know this might not be the best forum for this question, but since this thread currently has a lot of eyes on it I wanted to reach out and see if any one has experienced the same issue as me.
I am on a mid-2011 Mac Mini and I upgraded to Mountain Lion when it was released. Ever since I have been plagued with a freezing issue which is way worse than described by the OP.
What happens, 10-20 times per workday is the following:
I am in my workflow coding, sending e-mail, using Photoshop etc
At any seemingly random time, the app(s) I am using will become unresponsive
Soon after the Beachball appears and I cannot interact with most apps
After a period of time, usually between 10 seconds and 15 minutes (yes, minutes), everything un-freezes and goes back to normal
When the freezing happens, Chrome will not load webpages (stuck on "Waiting for cache" message). The Terminal will take forever to perform simple commands, such as "ls". TextMate will freeze when trying to save a file, or sometimes even when trying to input data. Finder will lock up totally.
At times during longer periods of freezing, there is a small burst of CPU cycles going through, so if I type "ls" in the Terminal, the command might execute after 40 seconds and then freeze again.
I have searched the web high and low for a solution, but haven't even found anyone with the same issue.
I have tried booting into safe mode, re-installing ML, uninstalling software, tampering with settings, isolating the behaviour to a certain app etc. I have found that the freezing occurs even after a clean reboot without starting any apps. There is nothing in the system logs. There is no extra network, cpu, memory or disk activity at the time. I have not found a single thing to pin this on.
Using Photoshop, Parallels and Skype seem to make the freezing more frequent, but they are not solely responsible for it.
Has anyone even seen this issue? At this point I have mostly given up on a solution, I am just looking for that "Who are you DenverCoder9? What did you see?" moment[1]
Is your disk healthy? That sounds like the behaviour of a dying harddisk (system locks up waiting for disk I/O as the harddisk retries, retries, retries until it finally gives up). Is there nothing in Console.app when this happens?
No, nothing in Console.app. I have run various disk diagnostics tools and they come up with nothing. My best guess is that it is the gfx drivers, but I have not found a way to manually re-install those on OS X.
I feel your pain, this happens to me too. I thought extra RAM would help, but it didn't. I thought a clean install would help, but it didn't. I hope "DenverCoder9" is out there. :)
Because safe mode is a different runlevel (IIRC), it gets the chance to run some maintenance scripts, delete caches, etc, uninhibited by some services that are loaded in normal mode.
I've had a few issues with ML locking up, some seem to be from this, others are from graphics updates being suspended. It's almost enough to push me back to SL honestly, but I need the later versions of XCode. Very annoying.
This problem is due to the protection, the sandboxing.
Various approaches have been suggested on the online forums, including editing the config files to be more lenient about these protections (the so called "alternative approach" proposed by the poster)
I tried them all, never had any result. I almost gave up, then read about that safe mode reboot suggestion. I have long uptimes and I don't want to bother reopening stuff, so I didn't do it immediately.
But finally I did, and it worked. Based on the timestamp of my blog (http://en.blog.guylhem.net/) I tried that on mar 31, about 1 month ago, and here are the results from the syslog so far (1 month of data after the fix):
lsboxd sqweaked only once in a month - and for something different.
I'd call this "problem solved", which is supported by my personal observation over this last month : I haven't experienced the problem again yet, while previously it was at least every 2 days (along with the TimeMachine always reindexing)
My suggestion: check your logs with the greps, try this simple fix and report your results in a month.
EDIT: This in on my macbookair with a 480GB OWC SSD (but apparently it also occurs on macbookair with vanilla apple ssds). I used istat menus, and still do. I didn't disable the dynamic pager, spotlight or anything else.
(EDIT2: removed) - thanks for the 4 spaces suggestion! as explained, the simple safe reboot solution made the problem go away, while other approaches didn't. It works for me, and I have 1 month of data supporting that.
> This problem is due to the protection, the sandboxing.
The problem of sandbox violation lines appearing in your Console is caused by sandboxing. It's unlikely that it goes any further than that.
The author has associated some other silent issue with his system to this one sandbox violation just because it happens to be printed all the time.
If you're experiencing some performance problem, run sysdiagnose(1) (or hit the key combo in its man page) and throw it into Apple's bug reporter. Or, if you stare at the output for a very long time, you might even figure out how to read it.
I'm rather annoyed as it seems like a simple "housekeeping" task that OS X should have already handled. When upgrading the OS, Apple always re-hides my user Library folder and wipes out my TRIM support kext for my "3rd party" SSD, but they cannot perform clean up like this? Very disappointing.
But my new MBP has been sluggish from day one. That is, from the moment I migrated my user files from my old box. It's possible that I got some stuff that affects performance. Three things helped:
* First, disabling the dynamic pager [1]. This one has a dramatic effect on performance. In theory, it will prevent OS X from swapping out apps unnecessarily (which it will do even when the apps are active and there is plenty of RAM). I did have some, but not much, swapping going on, but it still improved performance.
* Secondly, I uninstalled iStat Menus. I can't be sure that this contributed to the performance problems, but I won't risk reinstalling to find out. It seems to have helped a bit.
* Thirdly, I disabled Spotlight indexing of my home directory. This way Alfred will still autocomplete apps. Some apps lose their search functionality, but I never use Spotlight, and I find that I can live without it.
I tried the sandbox config fix, but it made no difference to me.
The remaining sluggishness seems to come from the graphics layer. For example, doing the Exposé "reveal all windows" command takes 3-4 seconds on my box and has a frame rate of approximately 1 fps. It's not great. I notice the reduced graphics performance when scrolling pages in Chrome, whereas Safari is smoother. I suspect this is Retina being a bit too ambitious compared to actual current graphics card performance.
As an aside, I believe OS X's I/O system has traditionally been its weak point, being a Mach-based hybrid-microkernel architecture. You can cause GUI scheduling problems by overloading the I/O system, and it's possible that this is exacerbated by having a SSD.