Closed x-ji closed 4 years ago
I saw the issue https://github.com/koekeishiya/yabai/issues/339 but I'm not sure if the fix is already in version 2.4.1
If an issue is closed and it has code changes related to it, then those changes are in the latest release. You can also go to the changelog and search for the issue number / id, to find the release that first included said change.
See this section of the wiki for how to access debug logs: https://github.com/koekeishiya/yabai/wiki/Configuration#debug-output-and-error-reporting
The next time you see this issue happening, open Activity Monitor, find the process entry for yabai, hit the info-button and create a sample. Post the output in this issue.
This might not help because I'm running 2.3.0, but just experienced this:
I'll upgrade to 2.4.1 and see if I can replicate there
Edit (koekeishiya): Made the sample output collapsable
So the sample provided by slifin appears to be something that I actually removed during a cleanup between version 2.3.0 and 2.4.0. I didn't actually think there was a bug in there.
So from what I can tell it seems that this piece of code just totally does not work the way I would expect it to, at least under certain circumstances (heavy load??).
The purpose there is to make sure that the mouse-click event is not forwarded to the target application if yabai is intercepting it.
I looked into the logs and they don't seem to show anything special. The only error I see in the error log is:
The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
But seeing from https://github.com/koekeishiya/yabai/issues/410, this seems to have already been addressed (the log might be old).
I'll try to get process info from Activity Monitor the next time this happens.
Taken when the CPU usage is above 20% (the process with the most CPU usage) on MBP 16''.
This does not make sense to me. Based on the sampling output, the 20% is spent inside the message_handler
function. Are you 100% certain that the actual running version of yabai is 2.4.1? I did not expect to see that function make calls to fflush
, fclose
:
+ ! 9 message_handler (in yabai) + 406 [0x10cb162e6]
+ ! : 9 fclose (in libsystem_c.dylib) + 83 [0x7fff6a7f9f4b]
+ ! : 9 __close_nocancel (in libsystem_kernel.dylib) + 10 [0x7fff6a8b466a]
+ ! 1 message_handler (in yabai) + 398 [0x10cb162de]
+ ! : 1 fflush (in libsystem_c.dylib) + 28 [0x7fff6a7fa163]
+ ! : 1 __sflush (in libsystem_c.dylib) + 98 [0x7fff6a7fa20e]
+ ! : 1 _swrite (in libsystem_c.dylib) + 87 [0x7fff6a80154f]
+ ! : 1 __write_nocancel (in libsystem_kernel.dylib) + 10 [0x7fff6a8b62ca]
This is the code in v2.4.1, which simply creates an event and queues it.
I also disassembled the released binary to double-check that there is indeed no calls being made to fflush
and fclose
.
static SOCKET_DAEMON_HANDLER(message_handler)
{
struct event *event = event_create_p1(&g_event_loop, DAEMON_MESSAGE, message, sockfd);
event_loop_post(&g_event_loop, event);
}
Version 2.3.0 looks like this and corresponds to your sampling output:
static SOCKET_DAEMON_HANDLER(message_handler)
{
FILE *rsp = fdopen(sockfd, "w");
if (!rsp) goto fderr;
volatile int status = EVENT_QUEUED;
struct event *event = event_create_p2(&g_event_loop, DAEMON_MESSAGE, message, length, rsp);
event->status = &status;
event_loop_post(&g_event_loop, event);
while (status == EVENT_QUEUED);
fflush(rsp);
fclose(rsp);
fderr:
socket_close(sockfd);
free(message);
}
Aside from that, it also appears to spend almost all that time processing query messages requesting space information: 462 space_manager_query_spaces_for_displays
.
462 calls to request space information over 3seconds seems like way to much.
Is there some application you are running that could be misconfigured?
I would recommend to make sure you stop the brew service, then reinstall yabai and make sure it outputs v2.4.1 when running yabai --version
, and then you should be good to start the brew service again.
Right. The installation on the MBP 16'' wasn't updated. I updated it now and let's see what happens.
Is there some application you are running that could be misconfigured?
Do you mean the displaying of the app could be misconfigured? If so how can I figure that out.
The sample with version 2.4.1:
Now the CPU usage is about 6 to 7 immediately after I started yabai
. Not sure if this is still too high.
By the way, I think the Übersicht widget from the documentation might actually have increased the CPU usage considerably. When I disable that widget, the CPU usage of yabai
went down considerably. Seems that constantly running the command /usr/local/bin/yabai -m query --spaces
is having some performance impact.
By the way, I think the Übersicht widget from the documentation
I don't recall there being a specific Übersicht widget in the documentation, only a link to Übersicht itself?
When I disable that widget, the CPU usage of yabai went down considerably. Seems that constantly running the command /usr/local/bin/yabai -m query --spaces is having some performance impact.
You probably have to set the refresh rate in the config of the Übersicht widget. Based on the sampling above there are 127 calls for the same query made per second.
Fairly certain that if you kill Übersicht the cpu usage of yabai drops down between 0-4% depending on the amount of mouse-movement performed.
I see. After some searching I realize that i actually got the widget from here: https://github.com/koekeishiya/yabai/issues/136#issuecomment-525480743
I guess the original issue is probably fixed in 2.4.1 and Übersicht was the cause of the additional CPU usage. I'll close the issue for now. If it happens again I can reopen or somebody can open a new issue.
Sometimes after I've started my machine for a while the CPU usage of
yabai
becomes very high (e.g. 50 to 60 percent, or sometimes even 99 percent) and slows everything down. It happens both on my MBP 13'' at work and MBP 16'' at home. Restartingyabai
works sometimes but doesn't fundamentally resolve the problem since it resurfaces soon. I have temporarily switched to another window manager because of this.Please tell me how I can attach more information/logs etc.
It seems to happen the most when I'm using multiple monitors.