Just upgraded to OSX 10.9 Mavericks. Everything is good and shiny. However, when I open my iTerm to code, I notice that the performance is lower. If I run a uptime command, the average loading is always bigger than 1 even if I run almost no other user process. Before the upgrade, the number is usually near 0.

Anybody got the same problem? Any idea how to solve it (except rollback to 10.8)?

  • 1
    I can't find any references, but checking my machines I suspect that the way the scheduler changed in Mavericks is affecting the load average (maybe the CPU doesn't wake up unless there's an app to run) and that 1.0 is now the new lower bound. I see the same behavior on otherwise idle systems. Oct 25, 2013 at 19:04
  • @AlanShutko I have surveyed 4 Macs running Mavericks and none has a load average above 0.86 at the moment with me ssh in to check on otherwise idle Macs. clwen - I would try to run top/iostat with an interval of 10s to make sure that your measuring things isn't adding to the run queue at the moment you look.
    – bmike
    Nov 9, 2013 at 20:20

6 Answers 6


Finally found the culprit. I'm using zsh and the plugin vi-mode from Oh-my-zsh interacts poorly with git tools. Disabling the plugin made my zsh usable again in terms of responsiveness and reducing CPU load.

There are conflicting reports whether Apple's git needs to be upgraded and you can follow that process at https://github.com/robbyrussell/oh-my-zsh/issues/2189

Still many thanks for all the people reply to the answer.

  • Now this is great - thanks so much for documenting the specific cause here and referencing the issue.
    – bmike
    Jan 7, 2014 at 18:15
  • 1
    Just tested. Switch to homebrew git also solves the problem. Even if vi-mode is enabled.
    – clwen
    Jan 7, 2014 at 20:02
  • I'm curious - what version of git is on your Mac? /usr/bin/git --version && sw_vers
    – bmike
    Jan 7, 2014 at 20:04
  • Apple git; homebrew git
    – clwen
    Jan 8, 2014 at 15:25

It is probably spotlight reindexing your system. Look up in your activity monitor which process is using the most computing time:

activite monitor

Alternatively you can click on your battery icon to see this information.

enter image description here

The problem should be gone in decent time.

  • Using activity monitor, I saw only kernal_task is using somewhat more CPU. However, it's just single digit.
    – clwen
    Oct 25, 2013 at 17:42
  • BTW, I've upgraded from the first day 10.9 released. So I suppose it's not because of reindexing unless it takes three days...
    – clwen
    Oct 25, 2013 at 18:52

If you cannot isolate a process that is actually taking CPU time now that should not (or did not before), then two things might be getting mixed up here:

uptime and top load averages are run queue average depth and not necessarily synonymous with CPU loading.

Yes, you need threads on the queue to have any chance to load the CPU, but just because there are 4 programs on the queue on average over a minute, doesn't mean that those threads together need to consume even 1% of the CPU time.

The real answer here will be to look at output like ps aux to determine which processes are actually running as opposed to sleeping and combine that with iostat to watch the actual CPU loading and see if you can determine if some new processes are running and whether that is increasing or decreasing the IO and CPU load on the system.


I contacted Apple about this, after being rather insistent I finally got a reply:

Apple Developer Relations 27-Mar-2014 10:54 PM

Engineering has provided the following:

It's a bug in the way load average is calculated, not something causing more system load.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.


I would use terminal and run

top -o cpu

That will give you an idea what apps are using your cpu cycles.


Just now, an iTerm2 update arrived that fixes this exact issue for me.


Mavericks fixes and performance improvements.

  • Fix bug where arrange horizontally computed the wrapping position incorrectly if the screen's visible frame wasn't 0
  • Set coprocess file descriptors nonblocking to avoid deadlock in bug 2576
  • Revert to old text drawing methods
  • Fix bug where the char under the cursor wasn't drawn
  • Fix bug where cursor blinked while moving
  • Fix crash in tmux with line drawing characters.
  • Fix a bug where a session would split using its old profile after its profile was changed.
  • Improve how font width is computed.
  • Fix occasional hang when a session terminates.
  • Hide menu bar on all screens in Mavericks in non-Lion fullscreen mode.
  • Speed up drawing in instant replay.
  • Update instructions for enabling access for asssitive devices on Mavericks.
  • Changes how text is drawn for improved performance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .