macOS Tahoe Prozess "WindowServer": liegt oft und kontinuierlich bei >50%

[jteschner]

@lisanet kennst du eine Möglichkeit/App, die mir die CPU%/GPU% Nutzung von WindowServer zB in der Menuzeile konzinuierlich anzeigt und ggf. sogar eine Warnung rausgibt, sollte ein Grenzwert überschritten sein?
Es ist ja keine Dauerlösung, dass ich ständig die Aktivitätsanzeige laufen habe.
Und Spark will ich auch nicht nutzen, da mir Mail.app mehr als ausreicht

 

[lisanet]

Genau das HATTE ich auch - allerdings war dies mit PB2 oder PB3 von Tahoe verschwunden. Aktuell habe ich ja Mail.app häufig geschlossen, um zu testen. Das geht *immer* ruckzuck.

hhmmm, ich habe ja Tahoe erst seit ein paar Tagen auf dem Studio und da habe ich ehrlich gesagt, gar nicht groß aufgepasst, ob Mail immer noch in einen timeout läuft. Vielleicht war es ja nur bei Sequoia der Fall. Du machst mit Hoffnung

 

[jteschner]

@lisanet kennst du eine Möglichkeit/App, die mir die CPU%/GPU% Nutzung von WindowServer zB in der Menuzeile konzinuierlich anzeigt und ggf. sogar eine Warnung rausgibt, sollte ein Grenzwert überschritten sein?
Es ist ja keine Dauerlösung, dass ich ständig die Aktivitätsanzeige laufen habe.
Und Spark will ich auch nicht nutzen, da mir Mail.app mehr als ausreicht

Habe selbst was gefunden (ChatGPT ist nützlich ): xbar in Kombi mit einem Mini-Script, das 1x/min ausgeführt wird (geht auch öfter)
Script:

#!/bin/bash

# CPU-Auslastung vom Prozess "WindowServer" ermitteln
cpu=$(ps -A -o %cpu,comm | grep WindowServer | awk '{print $1}')

# Falls leer, Standardwert 0 setzen
cpu=${cpu:-0}

# Ausgabe für Menüleiste
echo "WS_CPU: ${cpu}%"

Zeigt zwar nur jede Minute die CPU% des WindowServer an, aber ich weiss ja, dass diese dauerhaft >50% ist, falls es Probleme gibt.
Könnte man natürlich noch erweitern ...

Edit: xbar ist ja echt mächtig - vor allen Dingen die Community mit den hunderten existierenden Plugins ...

 

[jteschner]

Also, mein WindowServer verhält sich nach wie vor "normal". Die Aktionen wie in #38 beschrieben haben wohl tatsächlich zum Ziel geführt.

Nach wie vor offen:
Das "klemmen" von Mail.app nach einem längeren Stby, was den WindowServer in der CPU/GPU Nutzung wieder nach oben treibt - nicht immer aber regelmäßig. Irgendwas ist da noch ... Aber ich befürchte, dass *ich* dies nicht herausbekommen werde :-/

Zumindest beobachte ich noch weiter ---> "WindowServer CPU%" in Menu-Leiste mit Hilfe von xbar.app (ein tolles Tool finde ich - nur weniger für Anfänger geeignet). Aber wer es nicht kennt und wenigstens ein paar bash (oder swift, Perl, ... ) Kenntnisse hat, kann damit extrem viel anfangen und sollte es sich mal anschauen.

 

[lisanet]

Zumindest beobachte ich noch weiter ---> "WindowServer CPU%" in Menu-Leiste mit Hilfe von xbar.app (ein tolles Tool finde ich - nur weniger für Anfänger geeignet). Aber wer es nicht kennt und wenigstens ein paar bash (oder swift, Perl, ... ) Kenntnisse hat, kann damit extrem viel anfangen und sollte es sich mal anschauen.

Um temporär was zu monitoren, ist die App echt gut.

Dauerhaft mag ich zwischenzeitlich solche Monitoring-Tools nicht mehr in der Menüleiste. Da nehmen sie mir einfach zuviel Platz weg und die dauerende Anzeige irgendwelcher Werte finde ich, abseits von so einer Ursachensuche, eher unnötig.

Dennoch hat die App echt Potential.

 

[jteschner]

Um temporär was zu monitoren, ist die App echt gut.

Dauerhaft mag ich zwischenzeitlich solche Monitoring-Tools nicht mehr in der Menüleiste. Da nehmen sie mir einfach zuviel Platz weg und die dauerende Anzeige irgendwelcher Werte finde ich, abseits von so einer Ursachensuche, eher unnötig.

Dennoch hat die App echt Potential.

Ich werde sie auch nicht dauerhaft einsetzen. Dafür ist mir der Platz in der Menuzeile zu wichtig.
Aktuell sieht es bei mir so aus (wo es mal gerade nach einem Stdby hakt (war einkaufen):

Einmal Mail manuell abrufen und es geht wieder runter ...

Also, wenn du da was finden solltest oder noch einen zielführenden Tip hättest: ich geb nen Kaffee aus

Edit: wobei ich immer wieder feststelle, dass auch macuser.de mächtig Leistung verbrät ...

 

[lisanet]

Also, wenn du da was finden solltest oder noch einen zielführenden Tip hättest: ich geb nen Kaffee aus

ich habe gestern mal auf dem Studio das Verzeichnis Library/Mail aufgeräumt und ein paar alte Ordner gelöscht, die von Mail-Plguings übrig und das Plugin von Devonthink entfernt. Ebenso ein "lost+found" Verzeichnis.

Der Studio ist gestern dann problemlos per Zeitplan runter gefahren. Mail hat das nicht mit einem timeout verhindert. Ob das nun an Tahoe lag oder an der Säuberungsaktion, kann ich nicht sagen. Ich warte mal die nächsten Tage ab, wie der Studio runter fährt.

Ich beobachte aber keine CPU-Lasten. Die schwanken eh immer. Auch WindowServer, auch bim aufwachen aus dem sleep. Es scheint also diesbezüglich ganz normal zu sein, dass dort CPU-Leistung benötigt wird (ist für mich auch sinnvoll).

Mein Tipp also erst mal: Mail-Verzeichnis aufräumen

 

[jteschner]

ich habe gestern mal auf dem Studio das Verzeichnis Library/Mail aufgeräumt und ein paar alte Ordner gelöscht, die von Mail-Plguings übrig und das Plugin von Devonthink entfernt. Ebenso ein "lost+found" Verzeichnis.

Sehr gut.

Der Studio ist gestern dann problemlos per Zeitplan runter gefahren. Mail hat das nicht mit einem timeout verhindert. Ob das nun an Tahoe lag oder an der Säuberungsaktion, kann ich nicht sagen. Ich warte mal die nächsten Tage ab, wie der Studio runter fährt.

Ok.

Ich beobachte aber keine CPU-Lasten. Die schwanken eh immer. Auch WindowServer, auch bim aufwachen aus dem sleep. Es scheint also diesbezüglich ganz normal zu sein, dass dort CPU-Leistung benötigt wird (ist für mich auch sinnvoll).

Im Prinzip: natürlich
Aber ich sage es gern nochmal: Mein WindowServer schwankt im Falle das das Problem auftritt, nur noch oberhalb von 50% CPU und 70% GPU Last - und dies dauerhaft.

Mein Tipp also erst mal: Mail-Verzeichnis aufräumen

Ich hatte ja vorgestern bereits ~/Library/Mail/... komplett gelöscht und es wurde neu angelegt. Hier ein Screenshot:

Die kryptischen Ordner sind von iCloud, 2 x Strato und einer lokalen Mailbox auf dem MBP.
Das einzige, was ich noch machen könnte, wäre die Strato Mailboxen nochmal neu aufzusetzen - iCloud-Mail konfiguriert sich ja selbst richtig.

Meinst du, dass das Sinn macht oder fällt dir sonst etwas auf?

Edit: ich habe nochmal die Ports der Strato Postfächer gecheckt. Die waren beide für smtp auf 465 gesetzt (so wie es in der Doku steht. Allerdings ist die neuere Variante doch wohl 587. Nun habe ich den Port auf 587 geändert - mal schauen ...

 

[lisanet]

Meinst du, dass das Sinn macht oder fällt die sonst etwas auf?

Nein. Ich meine Verzeichnisse direkt in Library/Mail, alle außer V10. Da hast du keine.

BTW, falls du wissen willst, welcher UUID-Ordner zu welchem Account gehört, hier ein kleines script dafür:

#!/bin/zsh
osascript -e '
tell application "Mail"
set accountList to {}
repeat with a in every account
set end of accountList to name of a & ": " & id of a & "
"
end repeat
end tell
return accountList as text'

 

[lisanet]

Wenn du die hohe Last immer noch hast, dann musst du IMO wohl weiter in der systematischen Vorgehensweise gehen

Jetzt würde ich sehr systematisch vorgehen und alle Tools, Helferlein, Hintergrundobjekte, etc. der Reihe nach mal deaktiveren, diejenigen die tiefer ins System gehen ggf. auch mal testhalber deinstallieren.

Dabei würde ich diejenige nehmen, die was mit "Anzeige" zu tun haben, also mit Grafik, Video, oder andere Apps ergänzen, nutzen, die was mit "Anzeige" zu tun haben. Zudem soclhe, die nicht aus dem App store stammen.

Weiterhin würde ich Dinge, die mit Netzwerk zu tun haben ebenso prüfen. Auch hier solche, die nicht aus dem App Store stammen.

Wenn das alles nichts bringt, dann jene Apps der obigen Kategorien, die aus dem App Store stammen.

Wenn die Last runter geht, wenn Mail beendet wird, heißt es nicht zwangsläufig das Mail selbst die Ursache ist. Vielleicht auch nur ein Tool, App, Dienst, script das Mail aus dem Takt bringt.

Was macht eigentlich Obsidian? Greift das irgendwie auf Mails zu, oder bietet es Mail-Funtkionalität? Was ist mit der Mail-Funktionalität bei den rsync-scripten? Da hatte ich dir mal ein Apple-Script gegeben, mit dem man aus shell-scripten Mails versenden kann. Vielleicht ist daran ja was nicht ganz korrekt. Da wird ja doch eher brutal eingegriffen (senden und gleich wieder löschen / verschieben). Sowas kann auch nur dann auftreten, wenn der IMAP-Server vielleicht langsam ist und das Apple-Script schneller ist, als der Server nachkommt.

Versuche mal an solche Dinge zu denken.

 

[bmonno]

Gelöscht

 

[jteschner]

BTW, falls du wissen willst, welcher UUID-Ordner zu welchem Account gehört, hier ein kleines script dafür:

#!/bin/zsh
osascript -e '
tell application "Mail"
set accountList to {}
repeat with a in every account
set end of accountList to name of a & ": " & id of a & "
"
end repeat
end tell
return accountList as text'

funzt. Danke

 

[jteschner]

Wenn die Last runter geht, wenn Mail beendet wird, heißt es nicht zwangsläufig das Mail selbst die Ursache ist. Vielleicht auch nur ein Tool, App, Dienst, script das Mail aus dem Takt bringt.

Ich sage es gern nochmal: die Last geht runter, wenn ich in Mail einmal auf "Mail abholen" klicke. Ich muss es gar nicht beenden.
Ich habe aber aktuell/die letzten Tage nur Mail, Safari und Obsidian kontinuierlich laufen (Obsidian habe ich aber auch bereits mal deinstalliert --> kein Erfolg)

Was macht eigentlich Obsidian? Greift das irgendwie auf Mails zu, oder bietet es Mail-Funtkionalität?

Nein. Das Problem tritt aber auch ohne Obsidian auf.

Was ist mit der Mail-Funktionalität bei den rsync-scripten? Da hatte ich dir mal ein Apple-Script gegeben, mit dem man aus shell-scripten Mails versenden kann.

Gute Idee! Aber:
Das nutze ich zZt nicht bzw. schon seit einigen Wochen, da es mir zu viele Mails wurden - da hatte ich es übertrieben :-/ Mails werden mir aktuell nur vom NAS und der Homebridge geschickt.

Vielleicht ist daran ja was nicht ganz korrekt. Da wird ja doch eher brutal eingegriffen (senden und gleich wieder löschen / verschieben). Sowas kann auch nur dann auftreten, wenn der IMAP-Server vielleicht langsam ist und das Apple-Script schneller ist, als der Server nachkommt.

Daran hatte ich auch heute morgen gedacht. Ich habe ja zwei Mailboxen auf Strato, die ja beide "gleichzeitig" abgerufen werden ... nicht das da etwas klemmt.
Zudem war der smtp Server auf Port 465 eingestellt - das habe ich auf 587 geändert und beobachte das nun.

Nur nicht zu viele Änderungen auf einmal

 

[jteschner]

An den imap Konten lag es jedenfalls nicht. Ich habe sie komplett gelöscht (ausser iCloud-Mail) --> Null Erfolg
Auch alle Progs, eigene Scripte, LaunchAgents --> nichts
Sogar alle Programme beendet ausser Mail --> nada
Nochmal Reboot und nur Mail genutzt --> gleiches Problem

Habe mir gerade die PB16.1 installiert, in der Hoffnung ...
Zumindest gab es auch eine neue Version von Mail (Version 16.0 (3864.200.33)) - glaube ich zumindest, da es das beim Starten sinngemäß sagte

Schaun wa ma ... bislang: kein Problem

 

[jteschner]

Das Problem ist gelöst - meine restlichen 2%-Unzufriedenheit "are gone" und der WindowServer schwankt nur noch in den üblichen Bahnen.

Wie ich bereits vermutet hatte: "ich werde es nicht lösen können" - es war Apple.
Mit der PB 16.1 tritt es nicht mehr auf - was auch immer Apple getan hat - ich bekomme es nicht mehr reproduziert (was ich ja in den letzten Tagen sehr gut geschafft hatte).
Nun kann ich mich wieder interessanteren Dingen widmen ;-)

Dank an alle, die versucht haben zu helfen und gute Tips gegeben haben. Zumindest ist mein System wieder aufgeräumt und ich habe etwas dazugelernt

 

[lisanet]

Mein Problem mit dem timeout von Mail bei Herunterfahren scheint auch nicht mehr vorhanden zu sein. Ob es nun daran lag, dass ich das alte Plugin aus Library/Mail entfernt habe oder dass es das update auf Tahoe war, kann ich nicht sagen.

Da du aber erwähntest, dass diese Problem bei dir schon in einer der Betas von Tahoe verschwand, denke ich, dass es das update war und ich es nur noch nicht so wahrgenommen habe.

 

[jteschner]

Mein Problem mit dem timeout von Mail bei Herunterfahren scheint auch nicht mehr vorhanden zu sein. Ob es nun daran lag, dass ich das alte Plugin aus Library/Mail entfernt habe oder dass es das update auf Tahoe war, kann ich nicht sagen.

Da du aber erwähntest, dass diese Problem bei dir schon in einer der Betas von Tahoe verschwand, denke ich, dass es das update war und ich es nur noch nicht so wahrgenommen habe.

Sehr schön.
Nebenbei: ich hatte mal der Neugier wegen und weil etrecheck viele Crashs gemeldet hatte, über die Konsole in die Crash-Reports geschaut.
Da waren allein 26 von Mail zu sehen, bis zu dem Zeitpunkt als ich auf PB26.1 aktualisiert hatte.
Verstanden habe ich die Inhalte der Reports allerdings nicht :-/ fand ich aber trotzdem bezeichnend, da sie allein der Anzahl wegen herausstachen.

 

[Diedel]

Ich hatte exakt dasselbe Problem wie hier beschrieben. Aufgrund der Anregung habe ich die Beta installiert und das hat auch bei mir geholfen!

 

[ThoRo]

Kleine Ergänzung für diejenigen, bei denen sich das Problem nicht wie oben beschrieben lösen liess: es könnte auch eine laufende Elektron App sein;
https://www.heise.de/news/Unter-macOS-26-Tahoe-Riesen-Lag-bei-Electron-Apps-10688738.html

 

[thalesmilet]

Post gelöscht. ThoRo war schneller.