How do I debug an out-of-control "kernel_task" process?

Solution 1:

I had a similar question about how to identify files and programs connected to kernal_task using the following terminal command:

kextstat -l -k | awk '{n = sprintf("%d", $4); print n, $6}' | sort -n

This will display various kexts and the memory associated with them. For example, 6184960 com.apple.driver.AirPort.Brcm4360 is a big hog for me, but I can't do much about it if I want to use wifi.

One of the suggestions I received was to look up all non-Apple kexts are taking up memory by piping the above to grep -v com.apple. It's possible that some non-Apple programs are using up your resources. You should be able to remove those without breaking anything.

The age old solution of course is to restart your computer. Sometimes that's all it takes to set processes back to their normal levels of CPU usage.

Solution 2:

Here is a great explanation what a kernel_task is. It could be drivers (kexts), network or disk activity. You cannot simply use Instruments to attach to the kernel_task process.

Look for other signs, like logs (Console.app), disk activity (for example: iotop fs_usage), network activity (try disconnecting from local network, turning off devices in network preferences), try to uninstall/remove from memory (kextunload) drivers, which are from third party - tablets, usb 3g modems and etc. Check for applications, that are installing kexts

Also make sure that your file system is not corrupted, if you had any crashes recently - do a check.

Solution 3:

As mentioned by @Christopher, heat can cause the kernel_task CPU to spike. The reason is listed in this post “Fixing” kernel_task CPU Problems in MacOS Lion 10.7. Apparently when the CPU heats up the ACPI_SMC_PlatformPlugin.kext will take up CPU cycles in an attempt to reduce actual CPU load.

So one solution is to cool down your Mac (e.g. fan) through an external fan or something like SMCFanControl.

The article give another solution which is to remove the sub-kext that triggers that behavior. Though I must admit I am personally not sure about how safe it is to turn that behavior off.

Solution 4:

Usually kernel_task is out-of-control when some other processes are overusing system calls or resources (memory or disk I/O events).

When this happens, you can use fs_usage reporting utility which will show you system calls and page faults related to filesystem activity in real-time.

So run this command in Terminal:

sudo fs_usage

then observe which processes are frequently doing some system calls and if you're not using them, consider closing/killing them.

To be more specific, please check the TIME INTERVAL column which gives you elapsed time spent in the system call. A W appearing after elapsed time indicates the process was scheduled out activity (in that case the elapsed time includes the wait time).

So in order to filter the processes which are using the most time interval in the system calls, run:

sudo fs_usage | grep -v 0.0000

which will show you in the last column the most hungry processes (in terms of kernel time). You may adjust number of zeros for precision (less zeros displayed, more time spent).

For more ideas, also check: How to investigate high kernel task memory usage?

Here are the most common issues:

VBoxHeadless: if you're using VMs (via vagrant), consider suspending them when not in use;
mtmd: it seems Time Machine backups your data every hour even when your backup drive is not connected (so called local snapshots), so try disabling it (sudo tmutil disablelocal);
wine: if you're running Windows apps, consider closing them when not in use;
Chrome: limit number of tabs opened at the same time (try OneTab and/or TGS) or kill some Extension processes (JavaScript) via Task Manager, since each tab could generate a separate process.

^{Check: Chrome addon to stop “Page(s) Unresponsive” message.}