7

I updated to 10.10.4 on July 1, and ever since I've had very high CPU usage - roughly 270%, i.e. two and a half of four processors - by kernel_task.

It appears on login for about five minutes, then drops to 0. If I start Safari or Chrome or Parallels, it reappears, and this makes me wonder if it's related to the network. I know there were DNS changes in 10.10.4 - could it be related?

I have:

  • Tried running without external displays (there are several bugs about high CPU usage with an external monitor)
  • Removed all login items, and all automatically starting apps
  • Removed all items in /Library/LaunchAgents, /Library/LaunchDaemons, /Library/StartupItems
  • Checked I don't have anything odd installed. The only thing was flux, and I removed it. I do still have Crashplan installed but ensured it was set to only work twice a week - which is not today. I also have and use Parallels Desktop 10 (latest update), and sometimes it seems the high CPU usage is related to starting it. However, quitting it does not restore CPU usage to normal.
  • I don't think it is heat-related; the CPU temperature is the low end of normal, and fans are running normally, and the laptop has good airflow and I can't feel "hot" air coming from it, only normal temperature air.
  • Booted in safe mode. This was fine and I had normal CPU usage. This makes me think it must be a kernel driver or similar issue.
  • I ran EtreCheck, which shows the only kexts loaded are com.parallels.kext.hypervisor (10.2.1 29006 - SDK 10.7), com.parallels.kext.netbridge (10.2.1 29006 - SDK 10.7), com.parallels.kext.usbconnect (10.2.1 29006 - SDK 10.7), and com.parallels.kext.vnic (10.2.1 29006 - SDK 10.7).
  • However, my battery health is 'Check Battery' - could that be related? Despite the health status, it has done 590 cycles and this model is supposed to only be consumed at 1000. Odd; not sure why that would be / what it means.
  • System.log: nothing obvious. I sat watching it for several minutes and didn't see anything added to it. Scrolling back showed lots of messages, but nothing that seemed like fast repeated failures or anything that might explain constant CPU usage. I browsed the other logs as well and didn't spot anything.

Examining Activity Monitor, all CPU usage is shown as in kernel_task itself, not any descendant apps.

I have an early 2011 model 15" MBP, which up until 10.10.4 Yosemite ran really well on.

Any ideas on how to analyze and resolve the issue?

PS: Although the weather is hot (it's 35 degrees C - Europe is having a heatwave) it is unlikely to be this issue since smcFanControl shows a steady 65-67 degrees C, the low end of a normal temperature range. Both fans are spinning at 6000RPM, but that too is normal. Ambient temperature today and yesterday is the same as it was before I installed 10.10.4, but the high CPU usage of kernel_task occurred only when 10.10.4 was installed. That's the key difference. Something in relation to 10.10.4 causes high CPU usage.

15
  • There are a bunch of things which could cause kernel_task to run amok, see the answers to related questions (apple.stackexchange.com/search?q=kernel_task). Some of the answers also give some ideas about how/where to find out what kernel_task might be doing. A kext may very well be the cause here, but then either the system log or a step by step disabling of kext's (especially those not supplied by Apple) should give you some insights.
    – nohillside
    Commented Jul 5, 2015 at 11:25
  • Thanks @patrix . I've read most or all of those and so far as I can tell none apply. The kext thing is a possibility, but I don't have anything odd installed, so it might be one of the inbuilt drivers (?) - I suspect that especially since this problem was introduced by 10.10.4. I'll investigate those and update, though. Btw, since this was definitely introduced by 10.10.4, is it really "too broad" a question? I've narrowed it down from most things and it's OS-update-specific - that seems quite a specific question to me.
    – David
    Commented Jul 5, 2015 at 12:16
  • Is there anything of interest in the system.log?
    – nohillside
    Commented Jul 5, 2015 at 12:36
  • @patrix Edited to answer, but basically no, nothing. I have some Parallels kexts loaded (Parallels is fully up to date) and batter health of 'check battery' - maybe that could be related?
    – David
    Commented Jul 5, 2015 at 15:34
  • 1
    Three days ago, my kernel_task ran at about 400%-800% for about an hour, then calmed down and went back to normal. Now it's starting again. No Parallels kexts here; 10.10.4. Commented Jul 6, 2015 at 11:56

6 Answers 6

2

As far as I am concerned kernel_task was always trying to tell me that the computer is running hot. It seems to be a strange countermeasure which occupies the CPU with a low energy No-Op task which prevents it from doing "hotter" things. So you should be looking for that "other" process eating up the rest of your CPU time.

However I noticed very high CPU usage of Safari ever since I update do Yosemite 10.10.4. The browser visibly (in Activity Monitor) starts several processes now and two of them (Safari Networking and nsurlstoraged) routinely take up a lot of CPU, especially Safari Networking often takes more than 50% of one CPU. It seems to be less constant now, so maybe there is some "trickle down" effect on this one.

0

Answering my own question: I visited an Apple store a couple of days ago, and they opened it up and also ran a full suite of Apple diagnostic tests (a bit like the hardware test you can boot into, but much more extensive.) There was not much dust in the laptop; the fans were functioning normally; they have a special thermal test which tests heatsink connections and the laptop's reactions to high CPU load. This all passed fine.

For others experiencing this problem, I would recommend you book an appointment at the Genius Bar and ask them to clean dust out, check the heatsinks, and run a full hardware diagnostic. Even if you're happy opening up your Mac yourself, Apple provides its technicians with more extensive hardware diagnostic software than it provides us with.

The technician consulted with a few others and concluded the high kernel_task usage may simply be a software problem and recommended to reinstall Yosemite to a clean formatted disk, after a backup. (I suspect this is the "I don't know" answer.) I have not yet done this since the problem is occurring much less often now than when I posted.

0

I found one post that mentioned turning off Bluetooth and didn't even mention battery issues but issues with Bluetooth devices running on low battery...none of which I have; happy to report this actually resolved the issue immediately! Kernel_task CPU went right down, battery came back on line and my MacBook is lightning fast again!

1
  • "none of which I have" what do you mean? Did you have a bluetooth connected with a low battery? Commented Nov 1, 2016 at 22:48
0

I'll post my experience, which isn't quite a generic answer and probably not applicable to the OP. But still might help someone with battery-related issues causing this.

I had had an SSD failure and the repair shop (not Apple) replaced it. And also disconnected my battery, because they found that it was warping/swelling, which is an indication of possible future battery failures (think fire).

They also put Sierra on the new SSD.

Back home, I got a persistent 250-300% cpu kernel_task. I disabled Spotlight indexing, just in case. Noticed some messages in the Console about battery. Others about iCloud permissions, which I fixed just in case. Still lotsa kernel_task.

Then I took the Macbook Pro to the Genius bar. Took them about 5-10 minutes to run a hardware test which showed that the battery sensors were failing. Was told the kernel_task was due to this as the system assumes no battery heat data means an overheating battery (even though the system as a whole knows there is no battery).

Problem fixed with new battery (from Apple Store). I would also advise, if you buy a cheaper 3rd party battery, to have it put into the Mac when you buy it if possible - my much cheaper alternative in fact had the wrong connector (different year model). And other people have reported the smart sensors not recognizing bad replacement ones and causing kernel_task CPU throttling as well.

0

I was having this issue intermittently on MacOS 10.12.5 (Sierra) on a Mac Mini when playing games.

Below is an online statement posted by Apple posted and which helped me solve it:

If kernel_task is using a large percentage of your Mac CPU

One of the functions of the kernel task process is to help manage the temperature of your CPU.

Activity Monitor might show that a system process named kernel_task is using a large percentage of your CPU, and during this time you might notice more fan activity.

One of the functions of kernel_task is to help manage CPU temperature by making the CPU less available to processes that are using it intensely. In other words, kernel_task responds to conditions that cause your CPU to become too hot, even if your Mac doesn't feel hot to you. It does not itself cause those conditions. When the CPU temperature decreases, kernel_task automatically reduces its activity. Published Date: Feb 2, 2017

From here: https://support.apple.com/en-us/HT207359

The above Apple statement led me to a solution. There are several causes of this. Two of them are:

  • Broken or disconnected temperature sensor - In this case the fan is running ALL the time.
  • Clogged fan area - In this case fan spins up intermittently and kernal_task spins up grabbing a lot of CPU (500-1000%) during operations that generate a lot of heat, then when whatever activity causing the heat ceases it eventually stops.

In my cases the problem was intermittent and occurred when playing games. I solved it by taking the Mac Mini bottom off and vacuuming out the dust that was clogging the fans. This permanently eliminated the problem.

-3

just make a new account and move all your data to your account.. and whoola.. the kernel task is gone..

You must log in to answer this question.

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