This is probably a question best suited for Apple Support Forums, but after asking variants of this question there to no avail, I will try here instead.

I have a 2012/2013 2.3 GHz i7 Mac Mini w/ 16 GB that, over the 4-5 years I've owned it (since new) and has ran 4 versions of OS X/MacOS beautifully and efficiently. On the other hand, I have a 2015 MacBook Pro 13" i7 that I have rebuilt the OS from scratch twice and continues to be a pig (running the same apps) and is haunted by the every-present 1-2 GB Kernel Process of mystery which sits at the top of the Memory and CPU monitor pretty much all of the time. I have read blogs on this top recommending yanking out kernel extensions, but honestly I never tried getting that gritty since even the poster of said blog even said it was pretty much black magic and you were basically just picking stuff out without a lot of rhyme or reason. The KEXTs were just sort of "there and unnecessary" from "legacy platforms" and taking up resources. It sounded right, but the approach seemed so willy-nilly I never got aboard.

Anyway, I gave up on this years ago and I had pretty much just accepted that my MacBook was a pig and managed because at least my mini was zippy and clean, and has been for its entire life. That is until yesterday where it is now basically the same sloppy pig as my MBP. The only thing that would have changed that I was aware of was the most recent update. The weird thing is the MBP is running High Sierra where my hitherto rock-solid mini is still on Sierra but they now share the same miserable performance. I have no idea if this has anything to do with the recent storm of patches Apply has pushed in general, or just this last one, or something else entirely, but when I came to find my old but reliable (and fast) mini now has "the pox" I was pretty devastated.

Has anyone every gotten to the bottom of this vexing "kernel process" issue where it seems like all user action on the CPU seems to be force-multiplied for inexplicable reasons which just make the computer a pig all-around? I have asked Apple about this and I get the equivalent of a shrug. I had up until now just assumed that my MBP was just an inferior machine to the mini, since it remained slow and miserable even after a full reformat and reinstall, but now that my mini is poisoned I can see it's clearly more complicated that that as a week ago the mini was a flawless machine as it has been for 4-5 years (amazing for a computer for so long, yes) and is now, quite suddenly, painful to use, and the telltale sign is that accursed bloated kernel process that burns electricity even when the computer is literally doing nothing.

If you have any experience exorcising this particular demon I would be very interested in what you have to say because I don't even know where to start. I was on this quest for years and basically gave up assuming loss, but to give up TWO computers to this cancer just feels unacceptable. To start again would be starting anew, and I really hate even thinking of spending that much time on a fool's errand.

Thanks in advance.

Update 1/31/18: Since this issue is a very old problem that is simply rearing its ugly head somewhere I never thought that it would, it seems that there are many examples of articles that attempt to address this issue. While I haven't read anything that offers me much in the way of new information, it does validate that this is in fact a known problem but that it could be a symptom of any number of issues. One of them even references the blog article I had found previously about removing unnecessary Apple KEXTs that are vestigial/encumbering/problematic but you should do this at your peril. I still have a sense that "that can't be right" and "you're overthinking this" and that either (1) there is something else going on here that is a much simpler explanation or (2) there is a deep problem that affects the very core of MacOS handles resource management that is too difficult to solve by the lofty engineers who dare touch kernel code at Apple and too uncommon to make it worth messing with and therefore it remains an ignored elephant in someone else's room. I really hope it's (1).

Also, I have inspected the output of kextstat and the only third-party KEXTs are for virtualbox which I have been using for longer than I have owned this computer and have not updated in years (which I guess could be a good or bad thing) so unless a change JUST HAPPENED in MacOS that is suddenly not playing nice with these KEXTs, this is likely not the problem. Of course that doesn't rule out that the problem is KEXT-related.

I guess what it comes down to is that the activities required to isolate this problem are incredibly time consuming- as in it will take days to do the iterative troubleshooting required to identify the offending issue. This is in part because the problem itself is nebulous - some might say subjective - so from a QA standpoint there is no yes/no test for.

I suppose I could always just shitcan it and start with a fresh installation on a reformatted hard drive, but then the mystery remains and based on previous experiences on my MacBook Pro I would then expect that the problem will return anyway. The only way to insure against that would be getting things clean again and routinely booting from USB and performing a dd if=/dev/diskWhatever of=/Path/to/enormous/amounts/of/backup/space, most importantly before and after any system updates of any kind. This of course would enormously tedious and at that point I would give up, say enough's enough, and run Linux.

Update 3/5/18 I know this is getting to the point of being closed, but I have one more interesting report. I ended up frying my MBP 13”’s SSD when I spilled water on the keyboard and had it’s puffed up batteries replacing on Apple’s dime, and it basically got a free moboard, screen (there was a recall) and with the SSD which was under warranty, it’s basically a new computer. I did a TM restore onto the new, blank SSD (which restores the machine to the same state as the last backup, warts and all) and it’s super fast with the kernel process and window_manager running at quiet levels, so I am pretty sure the problem was hardware all along. This means my mini may be suffering from some sort of hardware sadness, but maybe not. I’m going to rebuild it and see. It’s never been since I bought it 5 years ago (always did “upgrade”) so it’s probably due!

  • 1
    Basically, kernel_task is the 'mother' of all processes. For it to be using a couple of GB RAM is not unusual, so there's nothing to 'fix'. If it's also using a lot of CPU, over 100% up to 500 or 600%, it's trying to cool your Mac down by forcing the fan speed to respond to the [actually fake] CPU figure. – Tetsujin Jan 30 '18 at 10:05
  • I am aware of the function of kernel_process in all of its incarnations on *nix-based operating systems. However, my mini has gone nearly 5 years and 4 OS upgrades while retaining excellent performance and without this process dominating the process table. Since the mini's performance went from "surprisingly responsive" to "painfully sluggish" literally overnight which directly corresponds to kernel_process dominating my process table with CPU and memory usage and that this same phenomenon exists on my MBP, I have to conclude this is a real problem. My question is how I might alleviate it. – Darf Nader Jan 30 '18 at 23:45
  • Have you considered that you might have a hardware problem with your CPU fans or similar? – jksoegaard Feb 1 '18 at 10:30
  • I don't know how experienced you are with programming (if at all), but the best way of debugging this to get an answer for sure is to profile the kernel using kgmon to see what exactly it is doing with all that CPU time. Ofcourse this presents itself with some troubles for an ordinary user, as you might solve your problem merely by replacing the kernel with a self-built one (as you mentioned that this could be simply caused by a point release of the kernel). You could consider using a second machine to debug the kernel with gdb - breaking every now and then to see what it is doing. – jksoegaard Feb 1 '18 at 10:35
  • Regarding the kernel extensions - I'm not sure if you're aware that you can just move the kernel extensions out of place temporarily to see if it fixes the problem, and move them back if it doesn't. It just takes a reboot to be absolutely sure. You can even unload them on runtime if you absolutely do not want to reboot (i.e. for testing with removing the VirtualBox kernel extensions from memory). – jksoegaard Feb 1 '18 at 10:36

You must log in to answer this question.

Browse other questions tagged .