38

2019 16" MBP running 10.15.4. WindowServer is eating a lot of CPU, idling at 10-20%-ish even with nothing much running. Fans are constantly going because of it.

I've disabled transparency and stopped (virtual) screens having their own spaces (as recommended elsewhere), to no avail. Also tried killing random things to see if anything sorts it out - no luck.

Running log stream --predicate '(process == "WindowServer")' --debug I can see it's dumping the following into its debug logs very frequently, 10+ times per second, which seems like it may be related:

2020-05-06 23:54:23.680073+0100 0x4e7 Debug 0x0 228 0 WindowServer: (CoreDisplay) [com.apple.CoreDisplay:default] [DEBUG] - On display 0x2b287853, surface is not detached, CoreDisplay is detached (0x00000000), DetachCode = 0

Any ideas what's going on?

Edit: as someone asked: The screens I was referring to are virtual screens. I do have an external monitor, but this still happens with it detached.

Dan
  • 561
  • Does quitting Safari help? It seems to, for me. (Just as a test; of course Safari is a pretty essential app to have open most of the time.) – tml May 09 '20 at 21:23
  • @tml Nope. Tried killing things randomly, tried no browser running, no matter what happens WindowServer will eat a fair bit of CPU. – Dan May 11 '20 at 00:01
  • 1
    What if you kill Finder? I've occasionally seen Finder windows and/or the desktop itself be the culprit for such things.CMD-OPT-ESC won't do it. In Terminal do this: defaults write com.apple.finder QuitMenuItem -bool true. Then: killall Finder. Note the Finder menu now has a Quit option in it. You can reverse that by changing the "true" to "false" in the first command. – Steve Chambers May 17 '20 at 15:34
  • I have the very same problem as described in the question. Killing Finder didn't change anything. I really wonder what surface is not detached in the --debug log is supposed to mean? – jolvi May 18 '20 at 12:14
  • Something similar, possibly related to IsAutoBrightnessEnabled:Yes, has been observed under Mojave. – jolvi May 18 '20 at 12:22
  • 1
    Based on this discussion, I turned off logging like sudo log config --process=$(pgrep WindowServer) --mode "level:off". Logging has stopped, but the CPU usage of WindowServer remains at 30%. – jolvi May 21 '20 at 10:44
  • You are talking of screen”s”. Do you mean external displays? How many have you? Please add this key information in your OQ. – dan Jun 01 '20 at 10:48
  • I have this INFO log message adjacent to every one of the DEBUG messages mentioned above CGXSetDisplayPolicyEnabled: doEnable 1 : sleepRelated 0 : firstTime -1 – Hari Honor Aug 10 '20 at 08:09
  • 2
    I also get it when I have no monitors plugged in. And when I plug in my second monitor, I get it twice as much with WindowServer CPU increasing accordingly. – Hari Honor Aug 10 '20 at 08:11
  • Macbook Pro 2016 Late Model has the same problem. I uses eGPU and 2 external Displays from the eGPU directly. Basically using Macbook's display makes to work internal GPU so, I used to use the Clamshell mode(close the lid) and uses my eGPU to work efficiently. – kakadais Jan 07 '21 at 04:14
  • The log stream was same to me, on internal or external GPU using. So using eGPU is my last option to use the machine easy. I tried a lot, not to use internal GPU but it just combined strongly with native application, so the best idea is Clamshell mode unfortunately still to me(even it still uses iGPU in somecase). Hopefully, someone could find a better solution.. – kakadais Jan 07 '21 at 04:19
  • Note log stream --debug command increases the WindowServer CPU usage visibly, you can tell by minimizing the Terminal it runs it. It draws a lot after all. Comparing with the top command I found that the Activity Monitor does too! – MarcH Jun 29 '21 at 02:53

7 Answers7

12

I have DELL UP3216Q external monitor. I had the same problem with "surface is not detached, CoreDisplay is detached" errors being spammed when I run log stream --predicate '(process == "WindowServer")' --debug. I'm using the external monitor with the Mac lid closed.

The errors stopped when I changed System Preferences > Displays > Display scaling settings so that scaling is not maximum on the external monitor. If I change the scaling back to maximum (more space) the errors start again on logging mode.

WindowServer CPU use was reduced slightly, but it is still around 30 %. Atleast the fan stopped spinning so fast.

Jari
  • 121
  • 2
  • 1
    Could this be because Mac uses some virtual display tech to render the screen?

    Looks like that also some of the lower resolution modes causes Mac to report errors. Check out the right setting for your monitor by starting the log and then changing scaling on your system.

     – Jari May 26 '20 at 13:18
  • 1
    I don't think it's to do with the resolution specifically, any non-HiDPI resolution seems to cause the problem. Using SetResX I'm able to select a HiDPI resolution that matches the monitor's native res and eliminate the errors. – Dan Aug 15 '20 at 12:13
  • Max resolution is already 1080p, so... – fuat Feb 26 '21 at 14:10
  • I have the issue on my MBP without external monitors. It goes away only when I choose "Scaled" and higher than default (so out of 5 levels that are available #4 and #5 work). If it's default or below default, I'm getting the debug message. – Dmitry Shvedov Mar 24 '22 at 23:01
9

Try https://chromeisbad.com/. In my case Google Chrome was the issue and uninstalling it (and, most important, Keystone) solved all my problems.

Elastic Lamb
  • 191
  • 2
    Just deleted Chrome/Keystone this morning and first impressions are that things are... better. WindowServer certainly peaks still, but it seems to settle down to ~5% CPU which it wasn't doing before. I'll reserve judgement until I've put a day's work through it but this might be the problem...! – Dan Mar 17 '21 at 10:03
  • 2
    Hm. Encouraging results to begin with, but after uninstalling Chrome and working with Firefox for a day... Not significantly better. – Dan Mar 18 '21 at 01:11
  • Also seeing improvement. The machine is cooler than before when idle, but still pretty warm. WindowServer still sits at around 7% usage. surface is not detached is still there in the logs. – Dmitry Shvedov Mar 24 '22 at 20:54
8

Answering my own question with what I've learned:

  • HiDPI resolutions eliminate the error message from the logs. SetResX has a HiDPI resolution for my monitor's native res - using that looks the same as the "more space" scaling, but without the errors. This reduces CPU use and heat a bit.

  • As dumb as it sounds, "clamshell mode" (ie, shutting the lid) helps quite a bit. I guess it helps not having to render the built-in screen

WindowServer is still using quite a bit more CPU than I'd like, but those two things have reduced it a fair bit.

Other things that I've seen others have success with but haven't been able to confirm myself: Using charging ports on the right rather than left reduces heat, and tweaking refresh rates by as little as 0.1Hz has dramatically reduces energy usage for some people.

EDIT: Clamshell mode seems to let me use the monitor's native res without using SetResX without causing the errors. I think this is down to having the machine render standard and HiDPI resolutions at the same time.

Dan
  • 561
  • 2
    Having read this I just switched my USB cable from left side to right, and saw an immediate drop in CPU usage from 30% to 10%. And that's even with the surface is not detached debug logs still streaming by (I don't like any of the other res options, and haven't yet installed SetResX to get deep into it). Thanks! – John Hart Aug 17 '20 at 16:37
  • @JohnHart Interesting. That made zero difference for me, but I'm glad it's helped you! – Dan Aug 17 '20 at 18:00
  • My issue is definitely with the built-in screen, but clamshell didn't help. Only setting scale on main screen to something above default makes the debug message go away. – Dmitry Shvedov Mar 24 '22 at 23:03
4

I, too, have run into consistently high WindowServer CPU usage since upgrading to Big Sur (a few weeks ago).

After upgrading to Big Sur I ran into generally sluggish window management / movement, and macOS feeling like it was "very tired", and have looked for answers for some time. Today things got really slow, with missed keystrokes while typing into iTerm, and WindowServer CPU usage running at 95% consistently. Reboots "solved" the problem for a while, but always after a short time things got slow again.

Then I found this article and the link to "Chrome is Bad". I followed the instructions (in Chrome is Bad) to remove Chrome and Keystone to the letter, rebooted, and switched to Brave.

The difference is literally night and day. Switching between apps / windows is now, once again, snappy. No more dropped keystrokes in iTerm and other apps. Moving windows from the internal display to my external (4K Dell) monitor is smooth as butter, where before it would become jerky as windows moved onto the external display.

I am still struggling to believe that Chrome / Keystone are the culprits—since neither shows high CPU when the problems show themselves—but I am (very) happy with the result.

In short, it will take a great deal for me to switch back to Chrome now, especially since all of my Chrome extensions work flawlessly in Brave.

Stuart Robertson
  • 41
  • 1
3

Macbook pro 2019 16 has a well-known problem regarding high CPU/GPU usage when external displays are connected (See related thread here). The problem is due to the fact that external display connection is hard-wired to external GPU. If you are using the computer with external displays attached, you can test to see if the problem continues when you detach all external displays.

Additionally, you can try to set the screen resolution to default if you are using one of the scaled modes. It is also well known that the scaled resolutions in MacOS tasks the CPU and GPU considerably.

Alper Kocatas
  • 1,241
  • 2
    Still happens with external displays disconnected. Non-scaled modes do reduce CPU usage a bit, but not enough to make the difference - it's still hammering the CPU enough that the fans are making a lot of noise even when idle. – Dan May 24 '20 at 15:43
  • 1
    Can you also try to setting the screen resolution to exact pixel doubled scaling? I believe it should be the "looks like 1536x960 option". This will rule out the scaling algorithm. – Alper Kocatas May 24 '20 at 15:45
  • 1
    I tried all resolutions and scaling options but the CPU usage stayed the same. I suspect it has something to do with the temperature since I never noticed an issue until August, when the temperature has stayed constantly above 30 Celsius. Still this should be a completely normal temperature range that a €3000+ laptop should be able to handle. Really frustrating. – xji Aug 13 '20 at 21:25
  • Thanks for the thread. With such a huge amount of replies it's clear that this has been an issue for quite a while and is likely caused by inadequate cooling for the heat produced by the CPU + dGPU combined. Using an eGPU apparently would solve it but feels like such an overkill. Having good ventilation (maybe even with a desktop fan) seems to help but it can only do so much. – xji Aug 13 '20 at 21:50
  • @AlperKocatas I'm sorry it's taken me so long to respond. Turns out when connected to an external monitor, if I select the "looks like 3200x1333" option, CPU usage is quite a lot more reasonable, and the log entries stop... Thank you! – Dan Aug 14 '20 at 22:28
2

I'm facing this too with messages like surface is not detached, CoreDisplay is detached for every screen I have connected, clam shelling didn't have a visible affect.

What did have an affect:

  1. Firefox 84.0.2, seems to have a significant change when I close it and open it (with 17 windows and probably 2-10 tabs each, I know it's a problem...).
  2. iTerm2 had the status bar on with many windows open too each with a status bar that was indicating Git Branch/CPU%/MEM%/Battery/etc. Disabling the status bar had the biggest effect on the WindowServer process.

13" MBP 2016, on Big Sur

joelpittet
  • 121
  • That iTerm thing is interesting, I basically always have it running (although not with the status bar)... – Dan Jan 26 '21 at 22:47
  • @Dan, the problem persists but more reasonable CPU% <50% normally and sometimes as low as 2%, that status bar had a huge role, I saw a couple GPU/kernel panics and before normally >100% and up to 850% CPU! Though wish I could find out more about surface is not detached, CoreDisplay is detached – joelpittet Jan 28 '21 at 00:57
  • For me iTerm was the culprit too. See the issue https://gitlab.com/gnachman/iterm2/-/issues/8640 – certainlyakey Jun 24 '22 at 21:04
1

My problems were completely identical with OP's, and my logs were showing the exact same results as well.

I tried many things to work this one out from my research on the Internet, but no luck.

In my case the issue was resolved by changing the refresh rate from 75Hz to 60Hz. I don't know the reason but it is magically decreased as soon as I did that. CPU usage is better than ever, no fan noise which was the most problematic issue for me. Also, changing Displays > Color > Display Profile from PHL245E1 to SD170M-A might have helped as well, but after I changed it back to HD one, no significant CPU increase or fan noise detected. Btw, I realized that the Color profiles have HD and SD modes, and in my case PHL245E1 profile is HD one while SD170M-A is, well, obviously the SD one. If someone has a 4K monitor and having issues like this, it might be of help checking these settings as well.

My system properties is like beloew btw:

  • MacBook Pro 15 Inch, 2019
  • macOS BigSur v11.3.1
  • External monitor: Philips 245E QHD

If there is anyone having the same issue and resolved it like this knows the real reason why, I'd love to hear that.

Burak Karakuş
  • 131