How to stop kernel_task from constantly using over 400% CPU? Configuration:


Model Name: Mac mini (Late 2012)
Model Identifier: Macmini6,2
System Version: OS X v10.11.3 (El Capitan)


For the past few weeks, kernel_task has been using over 400% CPU and its virtual memory size has ballooned up to 68.97 GB. Even after restarting, kernel_task starts hammering the CPU right away. In addition to kernel_task, there is also another process high up in Activity Monitor’s list that is always running and is constantly using between 90% to 100% of the CPU:


Python (running under the user: _devicemgr)


I’ve tried quitting this process, but to no avail… the process just reopens using the same amount of CPU resources.
As noted by Apple here:


  Activity Monitor may show that a process named kernel_task is using a large percentage of your CPU, and during this time you may notice a lot of fan activity. This process helps manage temperature by making the CPU less available to processes that are using the CPU intensely. In other words, kernel_task responds to conditions that cause your CPU to become too hot. When the temperature decreases, kernel_task automatically reduces its activity.


This would imply that kernel_task’s CPU usage will decrease once the process causing the CPU to overheat is stopped. Unfortunately, it was impossible to tell in Activity Monitor exactly what started the Python process owned by _devicemgr to begin with. Thankfully, someone else in this thread already did the detective work.

The steps I used to solve the problem:


Moved Server.app to the Trash.
Clicked OK in the Server app removal detected. dialog box: 
The Python process owned by _devicemgr finally stopped, and kernel_task’s CPU usage dropped dramatically to far more normal levels (3 – 10 %)… making my Mac finally usable again!




Optionally, Server.app can be moved out of the Trash and back into the Applications folder. I attempted this and reopened it. After starting back up and setting up services, it gave a curious error related to DeviceManager (which is quite interesting considering the CPU was being trashed for the past few weeks thanks to a process running under _devicemgr in the first place): 

More details in Console.app: 

In any case, clicking on Continue and ignoring the error doesn’t seem to have any negative repercussions (yet) and CPU usage hasn’t seemed to spike yet either, so I’d say problem solved!