kernel_task very high memory usage

[kubad]

Hello,
From a few week I have a problem with kernel_task process. It takes very high memory ( today its near 4gb of ram , I restart Mac yesterday when it takes a lot of more ~8gb)
Is anyone has this problem?

 

[chabig]

Kernel_task is a system process on your Mac that helps manage CPU temperature and performance. If it's using a lot of memory, it usually indicates that your Mac is overheating or that there are resource-intensive applications running.

The graph at the bottom of Activity Monitor shows green memory pressure and you're using zero swap. The machine is fine and not at all memory constrained. You don't have a memory problem.

Is your Mac running warm, or do you have a lot of peripherals attached? Does the CPU tab show an active process using a lot of CPU? Maybe high CPU demand is causing this. Perhaps try closing the Messenger tab in Safari. Facebook (Meta) has a reputation for writing resource intensive code.

Either way, I would not worry about it. Kernel task is an automatic function of the operating system. It's doing a job to protect your Mac.

 

[!!!]

Kernel_task is a system process on your Mac that helps manage CPU temperature and performance. If it's using a lot of memory, it usually indicates that your Mac is overheating or that there are resource-intensive applications running.

No, it's the OS and is responsible for nearly everything, task scheduling, memory, hardware, etc. Its RAM use has no direct relationship with the heat of the computer.

It can appear to use a lot of CPU when your computer is hot and very slow. This is just a side-effect of the reporting when the computer is thermal throttling, however. It's not really using the CPU, it's just limiting how much other processes can use.

 

[polyphenol]

Hello,
From a few week I have a problem with kernel_task process. It takes very high memory ( today its near 4gb of ram , I restart Mac yesterday when it takes a lot of more ~8gb)
Is anyone has this problem?

View attachment 2587633

Only 8gb? On my M1 MBP with 16GB memory it is currently taking over 11 GB. 🙂

But memory pressure is green. And the machine is running fairly well. So, whilst I am noting the fact, and am curious why it is so high, I'm not currently worried about it.

[ Adding ]
On my mac mini with 24GB, kernel_task is currently using 4.3 MB. A gigantic difference.

 

[maflynn]

At time, I think this is the equivalent to pixel peeping,where people obsesss over the individual pixels. The kernel is the the very core of the OS, and its memory needs fluctuate throughout the day.

Unless you're seeing issues, I'd not worry about keeping an eye on the performance monitor and its metrics.

Kernel's main responsibilities:

• Memory management
• CPU scheduling
• Hardware control
• Process and thread management
• Driver handling

 

[polyphenol]

At time, I think this is the equivalent to pixel peeping,where people obsesss over the individual pixels. The kernel is the the very core of the OS, and its memory needs fluctuate throughout the day.

Unless you're seeing issues, I'd not worry about keeping an eye on the performance monitor and its metrics.

Kernel's main responsibilities:

• Memory management
• CPU scheduling
• Hardware control
• Process and thread management
• Driver handling

In general, I agree. But when I saw the memory usage of kernel_task on my MBP, I was surprised. A restart has dropped it to about 10 MB.

Around a thousand-fold lower. More or less identical to my mac mini. That is not normal variation.

 

[maflynn]

In general, I agree. But when I saw the memory usage of kernel_task on my MBP, I was surprised. A restart has dropped it to about 10 MB.

But were you running low on ram? Was the ram pressure yellow or red?

Just because its using a lot of ram means there's an issue

 

[polyphenol]

But were you running low on ram? Was the ram pressure yellow or red?

Just because its using a lot of ram means there's an issue

As I said earlier "But memory pressure is green." 🙂

I think that there is an issue when something uses so much memory. The question is whether that issue is causing, or will cause, performance problems. For what I was doing, it wasn't. But I wanted to know whether restarting dropped it, or not. At least I now know that if it happens again, and it does cause performance issues, a restart is likely to fix it, at least for a while.

 

[maflynn]

I think that there is an issue when something uses so much memory.

Please explain. I don't have an intimate knowledge of how the kernel works, other then a high level topical understanding, but I'd like to learn more, so please let me know what's occurring with the higher memory utilization in the kernel_task and why its.

 

[polyphenol]

Please explain. I don't have an intimate knowledge of how the kernel works, other then a high level topical understanding, but I'd like to learn more, so please let me know what's occurring with the higher memory utilization in the kernel_task and why its.

I have not the slightest idea why it was happening. Sorry.

Just it is clearly wrong. Equivalent to three-quarters of the total installed memory being being allocated to kernel_task on one machine, and just a few megabytes on another. With both being used pretty much the same.

 

[kubad]

Today its looks like that :

 

[kubad]

It's ridiculous, but why it is happen?

 

[benwiggy]

If you're not seeing any slow-downs, freezing, or stuttering, then it's fine. The OS will manage memory according to its needs. Memory pressure is low; you've still got room for cached files, and you're not using any swap. (Not that swap is inherently a bad thing.)

iStat is brilliant at giving you numbers to worry about that are just normal operation.

 

[Abazigal]

If you're not seeing any slow-downs, freezing, or stuttering, then it's fine. The OS will manage memory according to its needs. Memory pressure is low; you've still got room for cached files, and you're not using any swap. (Not that swap is inherently a bad thing.)

iStat is brilliant at giving you numbers to worry about that are just normal operation.

Sorry to bump this thread, but on and off, I am experiencing an issue where the kernel task process starts taking up a lot of ram (sometimes over 10gb) and my M1 MBA (with 8gb ram) starts slowing down. I didn't realise it at first, and was wondering why my laptop was so sluggish. Restarting my laptop purged the file and everything was fast and smooth again. Once in a while, this seems to happen, at least I know what to look our for as well as a workaround (restarting my computer), but I am also wondering if there's a way to resolve this, or if this is a symptom of a larger issue (eg: insufficient ram?).

I don't really do intensive tasks on my MBA. Mostly browser and office related work, if that helps. ¯\_(ツ)_/¯

 

[benwiggy]

or if this is a symptom of a larger issue

The kernel task is the "mother of all tasks" and where a lot of the most basic operation occurs. However, 10Gb of memory usage does seem very large. (Mine is only 2.1 Megabytes currently.)
The kernel task can use up large amounts of CPU, as a response to overheating -- it basically "hogs" all the cycles so that real work is limited.

But large amounts of RAM is curious. I would suspect third-party software first. Next time it happens, quit all your apps, and see if that reduces it. Then test launching them one by one.

 

[ljungla]

I have the same problem when Safari is running. If I quit Safari the kernel_task memory consumption is heavily reduced.

Maybe some extension that is causing the problem. Haven't investigated that yet.

 

[phairphan]

Also experiencing this now: almost 140GB. As above, quitting Safari restored sanity. Still on Sequoia, and the only significant change in the past day or two was the Safari security update. Something hinky might be happening related to that.

 

[kurtk971]

I am on the latest (26.6.2) and also have this issue with kernel_task growing to many gigabytes over time even if all windows are closed. I ran a spindump on kernel_task, and got some AI help on the analysis:

What the dump shows​

The kernel's 6.6 GB footprint is GPU driver memory (AGX/IOGPUFamily/IOSurface), not a general kernel leak — and the client holding it open is Safari's GPU process, com.apple.WebKit.GPU, not Safari itself.

Key evidence:

1. The kernel-side stacks are all GPU driver, idle-blocked on cleanup The only non-idle kernel work in the trace touches:

• AGXAccelerator::idleUMAEvent → AGXUSCPrivMemPool:😛erformShrinkLocked → IOGPUSysMemory::free (lines 277–286)
• IOGPUScheduler::work_completed → IOFence::complete → IOSurfaceRoot::fence_completed (lines 635–641)
• IOMobileFramebufferAP::io_fence_callback (line 801)

Plus 65 InterruptEventSourceBridge and 40 AppleT8110DART (the memory-address-translation unit) threads in kernel_task — every active GPU client context keeps DART mappings and driver objects wired into the kernel. The kernel runs 670 stacks in IOWorkLoop::threadMain waiting on these. That's why the memory shows up attributed to kernel_task: IOSurface buffers and GPU command-queue memory are kernel-resident on behalf of whichever process has the GPU contexts open.

2. The smoking gun: stale WebGPU work queues in WebKit.GPU [pid 44258]

That process has 57 threads, including ~14 "WebGPU work queue" threads and ~10 ANGLE-Worker threads whose last ran timestamps are 1.8–8.4 hours old (e.g. last ran 30284.598s ago). These are GPU contexts created by pages/WebGPU content and never torn down — the work queues are alive, the kernel-side IOGPU objects and IOSurfaces they pinned can't be freed, and they keep the DART translation contexts (those 40 AppleT8110DART threads) resident.

3. Corroborating detail: 13 WebContent processes for "one tab"

Most are suspended but still alive (several with 128–575 MB footprints), plus a second, older com.apple.WebKit.GPU [pid 2139] alongside the current one — Safari isn't reaping its per-site processes, and each keeps kernel resources mapped.

Why quitting Safari "fixes" it​

When Safari exits, its WebKit.GPU process dies, its IOGPU user clients close, and the kernel finally frees the AGX allocator memory (AGXUSCPrivMemPool) and IOSurfaces. The memory doesn't "hang" in kernel_task while Safari lives because the kernel retains it on behalf of the still-open WebKit.GPU client — this is a WebKit/Safari WebGPU-context leak, not a kernel bug.

I've filed this as a bug using Apple's Feedback Assistant