Hallo allerseits,

seit geraumer Zeit kämpfe ich mit einem mysteriösen Phänomen, dass die GUI eines Macs wegen bestimmter Applikationen vollkommen einfriert, während der Unix-Unterbau (via ssh von außen betrachtet) völlig normal läuft (Mojave 10.14.6; war aber auch auf früheren Systemen schon so; ob auch auf späteren, weiß ich naturgegebenermaßen nicht).

Nun bin ich mittlerweile beim Verständnis insofern weiter, als ich mittlerweile weiß, dass alle diese Applikationen eines gemeinsam haben: Es sind entweder Webbrowser oder es sind Apps, die via Java Chromium starten, auf dem dann als die „eigentliche“ App eine Web-App läuft.

Für sich alleine ist jede App unauffällig. Es geht immer um mindestens zwei, schlimmer noch mehrere, die sich gegenseitig irgendwie beeinflussen. Am schlimmsten sind eine Börsenchart-App (mit Java und Chromium) und Firefox (wobei Safari auch nicht viel besser ist), weshalb ich mich exemplarisch jetzt auf diese beiden konzentriere.

Das Phänomen tritt auf, wenn zumindest eine der beiden Apps schon länger läuft. Irgendwann werden beide Apps immer langsamer. Ist Firefox vorne, kann das am Ende dazu führen, dass -N mehrere Minuten braucht, bis sich ein neues leeres Fenster öffnet, und bis zu 10 Minuten, bis eine dann eingegebene URL angezeigt wird. Immerhin bleiben der Rechner/alle anderen Programme ansonsten aber responsiv wie immer. Daher lässt sich im Aktivitätsmonitor auch beobachten, dass die CPU-Auslastung völlig normal bleibt (Firefox braucht in der Wartezeit oft nur 10-20% und keine CPU ist 100% ausgelastet) und auch die Grafikkarte ist in keiner Weise strapaziert (gemessen mit OpenGL Driver Monitor und iStat Menus).

Ist umgekehrt das Chartprogramm vorne, wird es zunehmend zäh und friert schließlich die gesamte GPU ein. Konkret heißt das, dass sich der Mauszeiger noch bewegen lässt, die Menüleistenuhr alle ca. 20s auf die aktuelle Zeit springt, ansonsten aber die gesamte GUI (aller Apps) eingefroren ist und der einzige Ausweg aus dieser Situation ein kill des Chartprogramms via ssh ist. Läuft Firefox schon länger und wird das Chartprogramm neu gestartet, kann es vorkommen, dass der Fensterrahmen des Login-Fensters erscheint, das Fenster aber leer/komplett weiß ist. Beende ich dann Firefox, taucht der Fensterinhalt sofort auf.

Auf Unix-Ebene funktioniert auch in diesem Fall alles problemlos; die Prozessorauslastung ist insgesamt gering.

Es gibt also ein „Nadelöhr“, durch das nur Webbrowser-Engines müssen, wo sie sich irgendwelche Ressourcen streitig machen (aber weder CPU noch GPU sind), während andere Apps (insbesondere auch Cocoa-Grafik-Apps) damit nichts zu tun haben.

Ich erhoffe mir keine Lösung mehr, aber würde das Problem zumindest doch gerne besser verstehen. Hat irgendjemand zumindest eine Idee, was das überhaupt sein könnte?

Was genau meinst du damit? Hast du dir mit "top" im Terminal alles anzeigen lassen? Vielleicht läßt sich da was erkennen.

Ja, habe ich. Prozessorauslastung aller Kerne ist irgendwas zwischen 20-40% (bei sehr vielen laufenden Programmen), alles total unauffällig.

Kann es sein, dass Java da der Flaschenhals ist? Welche Version wird denn da verwendet?

Das dachte ich zunächst auch, aber Firefox verwendet das doch gar nicht, wenn es gestartet wird, solange man keine Website mit einem Java Applet aufruft (was ich nicht tue)?

Ich kann nach dem nächsten Start von Firefox mal versuchen, Java Applets zu verbieten, aber ich glaube eher nicht, dass es das ist.
Auf dem Mac ist die 1.8.0 von Oracle installiert, aber das Chartprogramm, das sich täglich aktualisiert, bringt soweit ich sehe seine eigene Version mit.

Den Webbrowsern ist doch gemeinsam, dass sie viel RAM benötigen, insbesondere Chromium. Wenn ich die Prozesse nach Speicherbedarf sortiere, sind am oberen Ende die Hälfte Webseiten. Nicht zuletzt deshalb meide ich Electron-Apps.
Beim Umstieg auf Catalina gab es zudem Probleme mit Memory Leaks. Anwendungen wie Spotlight-Suche per Finder hatten einen ausufernden Speicherbedarf (mehrere GB für eine Suche) und der Speicher wurde nicht wieder freigegeben.
Du hast sehr viel RAM; wird dennoch der Swap genutzt?

Ich weiss genau was er meint, Tradingview bringt jeden mac in die knie, mehr als 4 charts und das system freezt, bei den Intel macs noch schlimmer. Bei meinem Air mit m1 geht es besser, kostet nur viel akku.

Moderne Webbrowser (und ich meine sogar Firefox macht das auch so) zeigen Webseiten über IOSurfaces (so was wie Texturen im Grafikspeicher) an. Der Grund dahinter ist, dass die grafische Benutzeroberfläche des Browsers und die einzelnen Webseiten in getrennten Prozessen laufen – aber irgendwie muss ja die Webseite in der Oberfläche gezeichnet werden. Dies ist eine sehr schnelle Möglichkeit, aus einem anderen Prozess Grafikdaten am Bildschirm darzustellen.

Und das scheint bei dir wohl irgendwie das Problem zu sein: Wenn "Unix-Land" normal funktioniert, aber die GUI bzw. der Window-Manager hängt, denke ich, dass hier der Flaschenhals zu suchen ist.

Sieh an, speziell Chromium wusste ich nicht.Hm, ich habe aktuell einen Swap von 15 GB (angesammelt allerdings über mehrere Tage), also ja, es wird geswappt. Das würde, gerade bei Memory Leaks, zu den ewigen Fensteröffnungszeiten von Firefox fassen (obwohl die auch dafür zu lang scheinen), aber eher weniger zu der eingefrorenen GUI.

Wenn ich nach physikalischem Speicherplatz sortiere, steht momentan der Kernel mit 10 GB an erster Stelle; ich meine mich aber zu erinnern, dass viele offene Webseiten irgendwie auch den Kernel aufblasen, obwohl sie ja zusätzlich eigene Prozesse haben. Die Chart-App ist Platz 2 mit 3,5 GB. Und dann kommen schon ein paar Web-Content-Prozesse, die sage und schreibe alle um die 1,2 GB zur Darstellung einer Webseite benötigen; den Webdesignern sollte man ihren Code um die Ohren hauen.

Aber ich habe ja 56 GB …

Aha, Tradingview auch? Da schaue ich nur selten und kurz rein. Gibt es da eine eigene App, oder läuft das bei Dir in einem Browserfenster?

Ah, das klingt sehr interessant! Ich lasse mir ioSurfacePageInBytes und ioSurfacePageOutBytes jetzt mal im OpenGL Driver Monitor anzeigen. Die OutBytes klingen mit 200 MB jetzt nicht so wild, aber die InBytes sind erstmal eine große Zahl (1,2 GB), deren Bedeutung ich natürlich überhaupt noch nicht einschätzen kann mangels Vergleich.

Weia
Beende doch einfach mal alles und beobachte diese Werte, wenn du nach einem Neustart nach und nach wieder deine gewohnten Apps startest.

Außerdem: Wenn ich mich recht erinnere, war Mojave die erste macOS-Version, welche Core Animation aus den Prozessen der Apps geholt hat und dies in den Window-Manager direkt verlagert hat (was einen großen Umbau bedeutete). Kannst du vielleicht auf eine modernere macOS-Version umsteigen? Vielleicht behebt das ja das Problem komplett ohne lange Recherche.

Ja, das erwäge ich ohnehin gerade, aber das braucht seine Zeit. Ich habe ja 2 Mac Pro 5,1, die nur noch via OpenCore über Mojave hinausgehen. Ich bin gerade dabei, einen umzubauen (Bluetooth-Hardware), dass er Monterey-fähig wird. Aber das ist halt mein nicht-Arbeits-Mac, den ich dann erstmal beobachten will, ob das gut geht.

Aber wenn Hoffnung besteht, dass das Problem damit von selbst verschwindet, kann ich auch noch warten. Nur schreibt ja itouch12, dass auf seinem M1-Mac mit einem vergleichbaren Programm Ähnliches auftritt.

Oben schrieb ich "Beim Umstieg auf Catalina gab es zudem Probleme mit Memory Leaks". Richtig ist, dass die Memory Leaks in Monterey auftraten. Das ist mit aktuellem Ventura behoben. Meiner Meinung nach ist das aktuelle Ventura bereits jetzt die bessere Wahl.
Zur Auswahl fand ich den Artikel vom bekannten Entwickler informativ (Stand bis MacOS 12.4)

Falls du externe Laufwerke verwendest, passiert das auch ohne?

Ich verwende keine.

Nur bei OpenCore hakt es da offenbar noch gewaltig.

Java Applets werden so mehreren Jahren gar nicht mehr unterstützt. Was für uralt Software betreibst Du da?

Gar keine. Die Frage war ja nur, ob das Problem an Java liegt, und dann hätte Firefox ja auch was mit Java zu tun haben müssen. Aber in der Tat führt eine Suche nach Java in den Einstellungen von Firefox zu keinem Ergebnis.

Das ist schwierig, das das Problem ja nie sofort auftritt, sondern immer erst nach einer gewissen Laufzeit. Ich müsste also, um ein aussagekräftiges Ergebnis zu bekommen, nach dem Start jeder App mindestens ein paar Stunden, besser einen Tag warten, bevor ich die nächste starte. Bei um die 100 Apps, die ich normalerweise offen habe, dauert das etwas zu lang …

Ich habe aber noch ein bisschen getestet:

Chartprogramm läuft, Firefox wird neu gestartet (mit Wiederherstellung der Fenster vom letzten Mal): Es dauert eine paar Minuten, bis die Fensterrahmen aufgehen; sie bleiben aber leer; kein Inhalt wird angezeigt. Auch nach einer halben Stunde kein einziges (von 11) Fenstern mit Inhalt, aber außerhalb von Firefox ist der Mac normal responsiv. CPU-Last und GPU-Last unspektakulär, meist unter 20%, nur ab und an ganz kurze ioSurfacePageInBytes, in der Regel 0. Keine Veränderung des verwendeten Swaps. Dann beende ich das Chartprogramm und in Sekundenschnelle haben alle Firefox-Fenster ihren Inhalt; dabei steigen auch (ganz normal) CPU-Last, GPU-Last und ioSurfacePageInBytes an. Letzteres bleibt ununterbrochen hoch, wenn ich eine lange, mit Fotos und Werbung überfrachtete Webseite betrachte, was auch stimmig erscheint.

Also sind weder CPU-Last noch GPU-Last noch Swapping noch ioSurfacePageInBytes der Grund für die Blockade. Das einzige, was mir aufgefallen ist (ich weiß aber noch nicht, ob das immer so ist), ist, dass sich der Speicherbedarf des Kernels in der Zeit der Blockade von 5 GB auf 10 GB verdoppelt.

Firefox läuft, Chartprogramm wird gestartet: CPU-Last, GPU-Last und ioSurfacePageInBytes wiederum unauffällig, verwendeter Swap ändert sich kontinuierlich (mal mehr, mal weniger): Das Login-Fenster wird angezeigt, aber zunächst leer; nach ca. 5 Minuten mit Inhalt. Nach dem Login lahmt der gesamte Rechner, kriegt aber diesmal noch die Kurve vor dem völligen Einfrieren. CPU-Last, GPU-Last, ioSurfacePageInBytes und verwendeter Swap weiterhin wie beim Login-Fenster. Wird ein aufwändiger Chart dargestellt, steigen CPU- und GPU-Last, aber in völlig vernünftigen Rahmen (60%-90% in einem Kernel). Kernel braucht wiederum 10 GB statt 5 GB.

Gibt keine "Java Applets" mehr. Die Technologie ist ausgebaut und kann nicht mehr verwendet werden.

Lösche doch mal die Preferences der Chart App.

Das hat gestern bei einem meiner Kunden auch geholfen. Dort war der Rechner ebenfalls langsam geworden, nachdem mein Rechnungsprogramm (FileMaker 18 Runtime) gestartet wurde (allerdings nicht so dramatisch wie bei Dir).

Wo siehst Du wie groß der Kernel ist? Wenn ich in der Aktivitätsanzeige nach Kernel suche, dann bekomme ich drei Prozesse angezeigt mit insgesamt 17 MB (M!).

Der kernel_task belegt bei mir in Monterey nach immerhin 21 Tagen uptime allerdings gerade nur so 25 offenen Websites 200 MB. Aber ich hab auch nur 8GB und nicht 56GB. Ich vermute mal, bei Weia ist das wieder ein Symptom von viel Speicher = viel Speichergebrauch, ohne dass das praktisch irgendwas heissen muss.

Tradingview via Chrome Browser, unter Firefox ist es nicht besser. Stock3 charts das selbe problem. Es liegt an der GPU, Charts fressen viel GPU. 4 Tradingview Charts mit scripte via Chrome am Air M1 = 30% CPU 38% GPU (1,9GB RAM) auslastung. Ich bestelle mir mal ein Mini mit m2 und hoffe das die GPU des m2 besser damit umgehen kann.

Nachtrag, am 18er Mini mit i7 zieht chrome bis zu 80% GPU bei Tradingview

Weia
Also ganz grundsätzlich ist dieses (wohl sehr schlecht geschriebene) Chartprogramm der Auslöser bzw. die Gemeinsamkeit, richtig? Wenn du etwas Zeit hast, mach doch mal folgendes:

1) Frisch Mojave auf externe SSD installieren
2) Davon booten, dann das Chart-Programm installieren und ggf. noch Firefox
3) Dann probieren, ob hier auch das Problem auftritt. Wenn ja, kannst du zumindest andere Ursachen ausschließen

Richtig.Werde ich mal versuchen, muss wegen Thema Zeit aber warten.

Da gibt es gar keine. Das wird alles auf dem Server des Brokers gespeichert.

Aktivitätsanzeige → Speicher → Spalte Physikalischer Speicher → Zeile kernel_task

Einfach weil es so einfach durchzuführen ist und damit dann als Ursache ausgeschlossen werden kann, würde ich sämtliche Caches löschen bzw. neu aufbauen lassen: Java-Cache, Kernel-Cache, Komponenten-Caches, Anwendung-Cache, DNS-Cache, dyld´s Shared Cache, XPC-Cache. Das lässt sich sehr komfortabel mit Cocktail oder Onyx machen.

Interessant wäre, was passiert, wenn Du die Trading-Apps bzw. eine davon mit Browser und Java in eine virtuelle Maschine packst. Möglicherweise ändert das die Konkurrenzsituation von der Du ausgehst.

Naja, so leicht durchzuführen ist das nicht, denn wenn alle Caches futsch sind, dauert es ja erstmal ewig, bis die Programme wieder nutzbar sind. Aber wenn ich eine Gelegenheit habe, werde ich das mal probieren.
Das finde ich eine super-interessante Idee, die ich als erstes von den zeitaufwändigeren Sachen testen werde. Dankeschön für den Tipp!

Ich weiß ja nicht ob es dazupasst aber wir haben auch durchaus Probleme mit Applikationen, welche Qt verwenden und auf MacBooks laufen. Framerates gehen gegen 0. Das Unix drunter läuft friedlich vor sich hin. Die GUI frieerst quasi ein. Qt hat da massive Probleme mit den Multitouchtrackpads.

Wo genau? Ich hab noch ein MBP von 2013 mit i7 und 8GB RAM, das ganz passabel mit Ventura unter OCLP läuft.

Beim Mac Pro 2012. Da beginne ich zu erwägen, OCLP zu installieren und registriere daher entsprechende Infos, ohne denen jetzt näher nachzugehen, zumal das ohnehin alles im steten Fluss ist. Und danach ist für diesen Mac augenblicklich Monterey problemlos und Ventura nicht. Ein Beispiel: Die ersten 5 Tage mit Ventura auf NICHT UNTERSTÜTZTEN Mac Pros und MacBooks!.

Habs mir angesehen.
Das Problem mit BT ließe sich durch einen kompatiblen Dongle lösen.
Das mit der Grafikbeschleunigung dürfte von der Graka abhängen.
Ich hatte einen Intel-PC mit einer AMD Radeon RX 580 damit versehen (nur testweise, da ich für manche Dinge eben einen PC brauche und natürlich ausprobiert habe, ob da Ventura läuft). Ich habe keine Probleme dieser Art mit OC gehabt. Das ist nicht ganz das gleiche System, und OCLP ist auch nicht OC.
Sicher kann ich es daher nicht sagen, dass es gut funktionieren wird. Du könntest aber in dem Form nachfragen, da dürfte es einig Leute geben, die sich damit auskennen:

PS: Wie hast Du diesen Link gemacht (dass man den Text sieht und kein Symbol)?

Der Dauerbrenner hier im Forum
Zitiere mal den Beitrag von Weia, dann wirst du es sehen

Danke, hat geholfen😁

Ich würde mich freuen, wenn Du berichtest, ob Du das GUI-Einfrieren so beheben konntest.

Ich auch, aber als erstes von den zeitaufwändigeren Sachen bedeutet leider frühestens in ein paar Wochen.

Weia: Danke für die Rückmeldung und viel Erfolg!