Kernel_task is using over 600% of my CPU and slowing things down to a crawl!!!

This is getting ridiculous. My late 2011 Macbook Pro 8,2 Intel Core i7 2.2 with 256GB SSD and 16GB RAM used to be so fast and snappy. But ever since a few months ago, it's been so slow. Kernel_task is using upwards of 600% of my CPU, my macbook pro heats up like crazy, and my fan becomes super loud. This is especially embarrassing in class or in the library, when it's completely silent (except for the lecturer in class), and my computer sounds like it's going to blast off into space. People actually turn their heads and stare. More seriously, it's almost impossible to use my computer because it is so slow. My intel core duo 2.0GHz mac mini with 2GB ram is actually faster than my macbook when this happens. I use very graphic heavy programs (this is why I have my computer), and I'm unable to use them smoothly anymore. Just previewing an image file takes like 3 mins to load up sometimes.


I've tried resetting the SMC, PRAM. I've ran the Apple Hardware Test. I've ran the Disk Utility to repair disk permissions and to verify the disk. Everything is fine. Running Console shows that there is no problem with the SMC. I've even downloaded Onyx and ran every maintenance thing on there. I've installed another user account, and installed another OSX on a different partition, and this Kernel_task craziness is ALWAYS there. It starts up randomly it seems, and it goes away after an hour or two. Then it starts up again after a few hours. It is maddening. It doesn't seem to be associated with any program. It happens when there are no programs running.


My mac's HD isn't encrypted. I do use Time Machine (but it's unencrypted) on a network drive. I'm at a loss as to what this can be. Please help me... This issue is driving me crazy. From my searches, it seems there are many others with the same exact problem. Yet no one seems to know of a solution.

MacBook Pro, OS X Mountain Lion (10.8.2)

Posted on Feb 17, 2013 6:02 PM

Reply
Question marked as Top-ranking reply

Posted on May 16, 2013 9:34 AM

I think, I have found a reliable fix!!!

http://www.rdoxenham.com/?p=259
In my case I have a faulty battery that shows a temp of 129°f (always) so the system average temp is way off…

This is a part hardware: (My battery going from Health:80% 333 cycles, to Health:7% after a reboot, I think this is do to the battery thermometer getting stuck on 129°f and battery controller safety shutdown)


After moving MacBookPro8_2.plist, I have to say my machine feels like its running as fast as it was new out of the box! I think Apple might be using that Kernal_Task(0) for more then just heat control.. It would make a very interesting marketing tool if you catch my drift..


CAUTION: KNOW HOW HOT YOUR COMPUTER GETS BEFORE YOU DO THIS.

IF NO ONE HAS CLEANED OUT THE HEAT SINK FANS IN OVER A YEAR DO THAT BEFORE APPLYING THIS FIX.. Better safe then sorry..


From: Rhys Oxenhams' Tech Blog

“Fixing” kernel_task CPU Problems in MacOS 10.7/10.8

Posted on June 5, 2012

Update (Early 2013): When I wrote this guide it was focusing on Lion 10.7, many people have, of course, upgraded to 10.8 and have reported success using the same principles. However, the plist entries have not been added for newer models, e.g. the new MacBook Air or MacBook Pro (+retina). Therefore, if you follow the guide exactly you may run into problems such as your model identifier not being visible. After diagnosing this with others via email it would appear that the system uses another plist in the directory, therefore removing all of the plists has worked. I cannot comment further or prove this to be the case as I don’t have the available hardware. Let me know whether this works for you…..

I use a wide variety of operating systems at home, all services are provided by Linux, e.g. firewall, routing, file-storage and DLNA media. However, I like using a Mac too, I have a late-2009 MacBook Air which I use whilst traveling. Despite all of Lion’s flaws, I really like using it- full-screen apps, gestures and the new Mail.app is really impressive. The specification of this machine really isn’t anything special, the lack of expansion really leaves a lot to be desired but for what I do- it’s plenty. I will certainly be upgrading to the new Ivy Bridge MacBook Air when it comes out, perhaps then I’ll have more than 2GB memory and can run VM’s too(!).

The biggest problem I’ve been having with this machine on Lion (didn’t have it on Snow Leopard) is to do with kernel_task. Instead of splitting all of the underlying kernel operations into their own individual processes (and associated threads) they are all consumed by a single ‘task’ (more of a representation of the underpinnings of the microkernel architecture) that appears in the process list. What I’ve been noticing is that this ‘task’ sometimes goes out of control, consumes CPU resources with the utmost priority. For a long time I wasn’t sure what it was doing, it seemed to be kicking in when I was doing something that was relatively intensive (for a Mac anyway), e.g. YouTube.

A lot of people suggested that ‘rogue kexts’ (kernel drivers/modules) could be causing the problem, perhaps an incompatible module was being started by OS X that was installed when the system was running Snow Leopard. This seemed to make sense as a boot in safe-mode would cause no problems. Suffice to say, I created a Lion Install-USB and re-installed from scratch; guess what… same problem within hours! After a bit of digging around and investigating the kernel_task ‘process’ it was clear to see that it was looping through something continually. After further research I discovered that the kernel will keep looping some very simple tasks, e.g. getting the date, therefore ‘consuming’ (with the highest priority) the majority of the CPU in a bid to cool the system down.

So, it’s all to do with temperature control- you ‘remove’ a large portion of the CPU share from other applications and carry out low-overhead tasks continually until the CPU temperature drops. This sounds like a great solution to cooling, but it’s very intrusive. It’s agressive nature drags the system to a halt in a lot of ways, despite the fact that the CPU in my MacBook Air rarely exceeds 70 degrees (centigrade). Considering the TJ Max of my little 2.13GHz Core2Duo is 85 degrees I’d rather kernel_task not take this invasive action.

Thankfully, this “feature” is built into a kext, in which each model identifier specifies how to control the temperature of the CPU via this invasive action. The simple fix is to remove the entry for your model identifier from this kext- if it “doesn’t know” what to do with your particular model, it won’t take any action. Now, here comes the disclaimer… by taking the same action as I will outline below, I take absolutely no responsibility for any damage or loss caused to you or your property, you do this of your own free will. You’re over-ruling functionality that was designed to prolong the life of your equipment, despite the fact that it’s invasive and very annoying it’s there for a reason. Anyway, on to the fun stuff…

Firstly, you’re going to need the model identifier of your pesky Mac:

$ system_profiler -detailLevel mini | grep "Model Identifier:"

Model Identifier: MacBookAir2,1

The kext we need to modify is IOPlatformPluginFamily.kext, you can verify it is running by-

sh-3.2# kextstat | grep IOPlatformPluginFamily

67 3 0xffffff7f81229000 0x7000 0x7000 com.apple.driver.IOPlatformPluginFamily (5.1.0d17) <8 7 6 5 4 3>

Within this kext will be another further kext- ACPI_SMC_PlatformPlugin.kext, in which each recent Macintosh model is listed with relevant instructions that the kernel uses to determine how and when to invoke the control. (Make sure you switch to root now)

sh-3.2# cd /System/Library/Extensions/IOPlatformPluginFamily.kext/

sh-3.2# cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/

sh-3.2# cd Contents/Resources/

sh-3.2# ls | wc -l

49

So, there’s 49 different profiles listed in this kext as of the writing of this. We simply need to move the ‘plist’ file for the model identifier we discovered earlier out of that directory, so in my case I need to move file ‘MacBookAir2_1.plist’ out of this directory (to somewhere safe), but replace my model identifier with your specific one.

sh-3.2# mv MacBookAir2_1.plist /Users/<your username>/

You can simply reboot now for the changes to take effect. We could have removed the entire kext but it’s much safer to remove the plist file for the specific model as (to be honest) I don’t know what the rest of that kernel module does. I’ve been using this ‘fix’ for a few days now and not noticed any problems at all- overall it’s much quicker and I don’t have to worry about it running out of steam. What I would recommend is that you be a bit more careful about the placement of your Mac, you don’t want to be covering the exhaust. The Mac should protect itself if it *does* reach max temperature but I would just be a little more careful.

Note: It’s likely that this kext will get updated in the future by Apple in their update packs and as a result will replace the file you deleted/moved therefore you may have to repeat this process in the future

Let me know how you get on.

41 replies
Question marked as Top-ranking reply

May 16, 2013 9:34 AM in response to asdllkjasdf

I think, I have found a reliable fix!!!

http://www.rdoxenham.com/?p=259
In my case I have a faulty battery that shows a temp of 129°f (always) so the system average temp is way off…

This is a part hardware: (My battery going from Health:80% 333 cycles, to Health:7% after a reboot, I think this is do to the battery thermometer getting stuck on 129°f and battery controller safety shutdown)


After moving MacBookPro8_2.plist, I have to say my machine feels like its running as fast as it was new out of the box! I think Apple might be using that Kernal_Task(0) for more then just heat control.. It would make a very interesting marketing tool if you catch my drift..


CAUTION: KNOW HOW HOT YOUR COMPUTER GETS BEFORE YOU DO THIS.

IF NO ONE HAS CLEANED OUT THE HEAT SINK FANS IN OVER A YEAR DO THAT BEFORE APPLYING THIS FIX.. Better safe then sorry..


From: Rhys Oxenhams' Tech Blog

“Fixing” kernel_task CPU Problems in MacOS 10.7/10.8

Posted on June 5, 2012

Update (Early 2013): When I wrote this guide it was focusing on Lion 10.7, many people have, of course, upgraded to 10.8 and have reported success using the same principles. However, the plist entries have not been added for newer models, e.g. the new MacBook Air or MacBook Pro (+retina). Therefore, if you follow the guide exactly you may run into problems such as your model identifier not being visible. After diagnosing this with others via email it would appear that the system uses another plist in the directory, therefore removing all of the plists has worked. I cannot comment further or prove this to be the case as I don’t have the available hardware. Let me know whether this works for you…..

I use a wide variety of operating systems at home, all services are provided by Linux, e.g. firewall, routing, file-storage and DLNA media. However, I like using a Mac too, I have a late-2009 MacBook Air which I use whilst traveling. Despite all of Lion’s flaws, I really like using it- full-screen apps, gestures and the new Mail.app is really impressive. The specification of this machine really isn’t anything special, the lack of expansion really leaves a lot to be desired but for what I do- it’s plenty. I will certainly be upgrading to the new Ivy Bridge MacBook Air when it comes out, perhaps then I’ll have more than 2GB memory and can run VM’s too(!).

The biggest problem I’ve been having with this machine on Lion (didn’t have it on Snow Leopard) is to do with kernel_task. Instead of splitting all of the underlying kernel operations into their own individual processes (and associated threads) they are all consumed by a single ‘task’ (more of a representation of the underpinnings of the microkernel architecture) that appears in the process list. What I’ve been noticing is that this ‘task’ sometimes goes out of control, consumes CPU resources with the utmost priority. For a long time I wasn’t sure what it was doing, it seemed to be kicking in when I was doing something that was relatively intensive (for a Mac anyway), e.g. YouTube.

A lot of people suggested that ‘rogue kexts’ (kernel drivers/modules) could be causing the problem, perhaps an incompatible module was being started by OS X that was installed when the system was running Snow Leopard. This seemed to make sense as a boot in safe-mode would cause no problems. Suffice to say, I created a Lion Install-USB and re-installed from scratch; guess what… same problem within hours! After a bit of digging around and investigating the kernel_task ‘process’ it was clear to see that it was looping through something continually. After further research I discovered that the kernel will keep looping some very simple tasks, e.g. getting the date, therefore ‘consuming’ (with the highest priority) the majority of the CPU in a bid to cool the system down.

So, it’s all to do with temperature control- you ‘remove’ a large portion of the CPU share from other applications and carry out low-overhead tasks continually until the CPU temperature drops. This sounds like a great solution to cooling, but it’s very intrusive. It’s agressive nature drags the system to a halt in a lot of ways, despite the fact that the CPU in my MacBook Air rarely exceeds 70 degrees (centigrade). Considering the TJ Max of my little 2.13GHz Core2Duo is 85 degrees I’d rather kernel_task not take this invasive action.

Thankfully, this “feature” is built into a kext, in which each model identifier specifies how to control the temperature of the CPU via this invasive action. The simple fix is to remove the entry for your model identifier from this kext- if it “doesn’t know” what to do with your particular model, it won’t take any action. Now, here comes the disclaimer… by taking the same action as I will outline below, I take absolutely no responsibility for any damage or loss caused to you or your property, you do this of your own free will. You’re over-ruling functionality that was designed to prolong the life of your equipment, despite the fact that it’s invasive and very annoying it’s there for a reason. Anyway, on to the fun stuff…

Firstly, you’re going to need the model identifier of your pesky Mac:

$ system_profiler -detailLevel mini | grep "Model Identifier:"

Model Identifier: MacBookAir2,1

The kext we need to modify is IOPlatformPluginFamily.kext, you can verify it is running by-

sh-3.2# kextstat | grep IOPlatformPluginFamily

67 3 0xffffff7f81229000 0x7000 0x7000 com.apple.driver.IOPlatformPluginFamily (5.1.0d17) <8 7 6 5 4 3>

Within this kext will be another further kext- ACPI_SMC_PlatformPlugin.kext, in which each recent Macintosh model is listed with relevant instructions that the kernel uses to determine how and when to invoke the control. (Make sure you switch to root now)

sh-3.2# cd /System/Library/Extensions/IOPlatformPluginFamily.kext/

sh-3.2# cd Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/

sh-3.2# cd Contents/Resources/

sh-3.2# ls | wc -l

49

So, there’s 49 different profiles listed in this kext as of the writing of this. We simply need to move the ‘plist’ file for the model identifier we discovered earlier out of that directory, so in my case I need to move file ‘MacBookAir2_1.plist’ out of this directory (to somewhere safe), but replace my model identifier with your specific one.

sh-3.2# mv MacBookAir2_1.plist /Users/<your username>/

You can simply reboot now for the changes to take effect. We could have removed the entire kext but it’s much safer to remove the plist file for the specific model as (to be honest) I don’t know what the rest of that kernel module does. I’ve been using this ‘fix’ for a few days now and not noticed any problems at all- overall it’s much quicker and I don’t have to worry about it running out of steam. What I would recommend is that you be a bit more careful about the placement of your Mac, you don’t want to be covering the exhaust. The Mac should protect itself if it *does* reach max temperature but I would just be a little more careful.

Note: It’s likely that this kext will get updated in the future by Apple in their update packs and as a result will replace the file you deleted/moved therefore you may have to repeat this process in the future

Let me know how you get on.

Oct 3, 2013 5:06 PM in response to asdllkjasdf

I took the back off of my 11" mid-2011 Macbook Air and carefully blew out the filters and the fan (I held the fan with a finger to keep it from rotating). It did not look initially like there was much dust but some significant dust bunnies came running out. Put the back on and started it up and kernel_task is behaving beautifully. I went from 200-500% CPU to 7-8%.


Clearly, in my case, it was a simple case of reduced air flow because of dirt that was leading to overheating. I didn't do anything fancy. Just an aerosol can of compressed air from Radio Shack.

Sep 20, 2013 1:46 AM in response to asdllkjasdf

Thanks for your help


I'd the same proble : Kernel_task using +600%

my MacbookPro (C2i7-2GHZ, 8GB RAM,10.8.3) was a nightmare, imossible to use textedit for example,...


i follow the instructions : identify my machine type and after remove file MacBookPro8_2.plist

and after the reboot : my machine is like a super car


So thanks , and i hope that it will be the same for users with the same problem : Too slow machine



share this fix !



Christophe

Aug 30, 2013 6:12 PM in response to Linc Davis

The answer is no, this is only a short-term fix to a larger hardware failure.. In the end you need to replace the hardware giving the bad sensor data.. YES the fix is Replace the Hardware thats broken (In my case a battery sensor)


This fix is "safe" because all the kernaltask0 overheat safeguards (Ironically putting the CPU at 600%) are really a redundant piece of software to the OverHeat kill switch in the hardware of the motherboard… Trust me, Windows 7 Bootcamp does Not use kernaltask0, as a heat reduction solution!!! When you macbook pro overheats on windows, the mother board crashes the system to protect the parts from heat damage with a significant margin for error too.. 99.9% of all computers have this safeguard, even your iPhone or smartphone..


So why add this software at all??




If ever I have problems with kerneltask0 again I will not hesitate to move my Macs identifier file (MacBookPro8_2.plist) again..


Its just more Annoying then its worth.


I hope other’s find this helpfull


<Edited by Host>

Dec 15, 2013 4:54 AM in response to seabas917

In case this helps anyone...


My Late 2012 iMac 27", 3.4GHz i7, GTX 680MX, developed this issue. No entry in plist for this machine either, and the 'remove all plist entries' fix had no effect on the problem for me.


Luckily I had actually purchased the machine in May '13, so it was still under warranty. Worked with Apple Support online, and when Hardware Test failed three times in a row (got to 16 seconds tested, hung for a few min than shut down each time) they agreed it was a hardware problem.


5 days, a new fan and new logic board later (all covered, thank goodness), machine is back to normal.


Moral of the story is that, at least for me, the root cause *is* a hardware issue.

Sep 11, 2017 7:51 AM in response to asdllkjasdf

After having struggled with this for a year now, I found what was causing my 600%+ kernel problem. I run mavericks on a MBP 2012 i7, 16 GB RAM. It was the GPU overreacting to my external monitor. There are more descriptive answers elsewhere. Anyway, now when I start to get the kernel black magic happening, I simply unplug my external monitor and within 20 seconds the system is back to normal.

Mar 26, 2014 6:22 AM in response to seabas917

My comment from original article of this tweak/hack about ACPI_SMC_PlatformPlugin.kext :


Actually another thing what deleting this plist results in, is it disables Turbo Boost 2011 and up machines. This isn’t necessarily a bad thing, cause in my case, I have MBA 2011 mid 13inch i5 1.7ghz, it actually reduced the CPU temp under full 100% load from 99C to 84C, fan speed decreased as well from 6.5k to 4.7k. Now the reason for that, is that TDP actually decreased from 18W to 10W, while CPU frequency remains at stable 1.7Ghz at all times. I can’t quite explain the TDP and temp difference, as Turbo boost supposed to work only when one core is fully utilized and the other is pretty much idle. But one theory which comes to my mind is that 18W TDP is actually way more than needed for most chips to run at 1.7Ghz 100% load, meaning that whilst you get that short burst of perfomance (overclock) above the total of 1.7ghz on all cores till you hit 99-100C, this kind of temperature is certainly not doing any good for machine. IMHO TurboBoost is poorly implemented on those machines, but funny enoudh I doubt there is someone to point fingers at, according to specs, Intel’s chip supposed to use 17W running at 1.7Ghz, yet they managed to make one able to run at 1.7ghz with only 10W tdp. Now Apples turbo boost config works according to the Intel specs, it sets the maximum frequency possible to stay at 17W till it hits some 99C, but since it doesn’t take to the account that varying per chip TOTAL frequency (NOT per core/turbo boost) can become higher than stated in specs, it actually overclocks the chip. I believe Apple missed there a great opportunity to take advantage of intel chips and fix heat/noise issues and ironically, save battery power (what this plist file intended to do in the first place).The only “downside” would be that every chip is different, so the temperatures under load would vary abit from model to model, but then again, turbo boost freqs are varying as well, moreover, remember that big story about toshiba vs samsung SSDs in MBA 2011? haha.

Feb 17, 2013 6:24 PM in response to asdllkjasdf

The kernel is using excessive processor cycles. Below is a partial list of causes for this condition.

Throttling

When it gets high temperature readings from the hardware, the kernel may try to compensate by interrupting the processor(s) to slow them down and reduce heat dissipation. This condition can be due to an accumulation of dust, to high ambient temperature, or to the malfunction of a cooling fan or temperature sensor. Note that if the problem is caused by a faulty sensor that reads too high, there may be no actual overheating.

The Apple Hardware Test, though not very reliable, is sometimes able to detect a bad fan or temperature sensor.

Using Apple Hardware Test


Encryption

Transferring large amounts of data to or from an encrypted disk image or FileVault volume may put an extra load on the kernel. If both the source and the destination are encrypted, the load may be doubled. If you transfer data from an encrypted disk image on an encrypted partition to another such image on another encrypted partition, the load may be quadrupled.

This issue probably doesn't affect late-model Macs with an Intel i-series, recent Xeon, or later processor. Those processors support hardware-accelerated encryption. You can determine what kind of processor you have by selecting About This Mac from the Apple menu in the menu bar.

Installed software

User-installed software that includes a device driver or other kernel code may thrash the kernel. Some system-monitoring applications, such as "iStat," can also contribute to the problem. You can test for this possibility by completely disabling or removing the software according to the developer's instructions, or booting in safe mode (with the shift key held down at the startup chime.) Note, however, that disabling a system modification without removing it or booting in safe mode may not be as easy as you think it is.

Corrupt NVRAM or SMC data

In some cases the condition has reportedly been cleared up by resetting the NVRAM or the SMC. I can't confirm.

Mar 20, 2013 6:26 AM in response to asdllkjasdf

Triple-click anywhere in the line below to select it:


kextstat -kl | awk '!/com\.apple/{printf "%s %s\n", $6, $7}'


Copy the selected text to the Clipboard (command-C).


Launch the Terminal application in any of the following ways:


☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)


☞ In the Finder, select Go Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.


☞ Open LaunchPad. Click Utilities, then Terminal in the icon grid.


Paste into the Terminal window (command-V).


Post any lines of output that appear below what you entered — the text, please, not a screenshot.

Oct 1, 2013 2:45 PM in response to Linc Davis

@Linc


Everywhere this problem pops up you're being deliberately obtuse and disingenuous. In multiple ways.


You know exactly what causes this problem.


You know many of the different fixes, and at least a couple of the "fixes".


Why do you act like people are sufficiently stupid to deserve your misleading ways about this?


++++++ For everyone else ++++++


The most likely cause of this problem is a build up of dust in your fans/vents or other disablments, inefficiencies, misreports or fails in your cooling system leading the operating system to believe (rightly or wrongly) that your system is overly hot.


There are two approaches to solving this:


1. Find the source of excess heat build up (or misrepresenation of that heat build up) and fix it.


2. Over-ride the method the software (Operating System) is using to clamp CPU use (kernal_task) activation.


If I knew how to achieve 2, within a Retina Macbook Pro, I'd be very happy right now. But I don't. Anyone know?


**** Generally speaking you shouldn't over-ride something "protecting" your system unless it's doing so unncessarily, or you're knowingly doing something that requires FULL CPU use for extended periods... like rendering or compiling.

Oct 4, 2013 4:16 AM in response to Warren Allgyer

As annoying as it sounds, your use case, is actually the way Kernel task is meant to work... For everyone else on this form who had the Macbook8,2 or older this would happen regardless of rendering or processing at all.


It really sounds like the Newer thiner Retina MacBooks, may have a really hard time dispersing heat.. If this is the case, I would NOT modify the plist because there are other parts of the computer that can break or even explode if heat is not dispersed properly. Its thinner too, making that all the more difficult..



Clean out out your fans.. • Difficulty: Difficult


http://www.ifixit.com/Guide/Replacing+MacBook+Pro+15-Inch+Retina+Display+Mid+201 2+Left+Fan/9719/1


Let me suggest, compressed air is really ineffective on the squirrel fans, in the Mac line up.

I messier about 1cm Of dust buildup per year in the Macbook8,2.. Your going to need a person who good at opening electronics, to remove the fans clean them and reinstall them.
This also makes the computer completely silent.. Like it was out of the box.

Sep 16, 2015 4:24 PM in response to Keale

Boot into Safe mode. Does kernel task still consume 600%. If not, then it is some 3rd party addition you have on your system.

<http://support.apple.com/kb/ht1564>


Suggest you start a new thread.

Post every bit of information Linc has asked for.


Maybe even post the output from EtreCheck (Linc will not look at that, but others might).

<https://discussions.apple.com/docs/DOC-6174>


Continuing to post in this thread is likely to be lost as it is a) long, b) chances are the original post is not the problem you are experiencing, so that just confuses things. Start you own thread and provide as much information as possible.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Kernel_task is using over 600% of my CPU and slowing things down to a crawl!!!

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.