Mac-Arbeitsspeicher: Warum die Summe der Apps zu hoch ist

Das Problem. Der Arbeitsspeicher aller Apps auf einem Mac ergab zusammengezählt 37,04 GB, während der Mac 29,73 GB als belegt meldete. Speicher, den sich mehrere Apps teilen, wird bei jeder App einmal gezählt.
Was wir herausgefunden haben. Beendest du eine App, kommt weniger zurück, als ihre Zeile vermuten lässt. Für eine Auswahl von Apps sagte unsere eigene Menüleiste 10,66 GB zum Freigeben zu, ehrlich gerechnet waren es 8,5 GB.
Was wir gebaut haben. Jede Ansicht in Mint, die zusagt, wie viel Arbeitsspeicher frei wird, rechnet jetzt mit dem, was tatsächlich zurückkommt. Eine Zeile, hinter der Arbeit steckt, etwa ein Terminal, in dem Claude Code läuft, wird aufgeführt, Mint hakt sie aber nicht von sich aus an.

Bevor du Apps beendest, um Arbeitsspeicher freizugeben, prüf, was die Zahlen eigentlich messen. Wer die gemeldete Nutzung aller Apps addiert, zählt gemeinsam genutzten Speicher womöglich mehrfach, und diese Summe ist deshalb keine Zusage dafür, was du zurückbekommst. Unsere Messungen auf einem Mac zeigen den Unterschied. Sie zeigen auch, warum ein Terminal, in dem ein Coding-Agent läuft, nicht schon deshalb als im Leerlauf gelten sollte, weil es im Hintergrund ist.

Wenn dein Mac langsamer wird, während ein Agent noch arbeitet, fang mit der Anleitung zum Prüfen des Arbeitsspeichers bei laufenden KI-Aufgaben an. Sie erklärt den Speicherdruck, welche Apps du beenden könntest und wie du das Ergebnis überprüfst.

Frag jeden Prozess auf einem Mac, wie viel Arbeitsspeicher er nutzt, zähl die Antworten zusammen, und du kommst auf mehr, als der Mac selbst angibt. An einem Nachmittag ergab die Summe 37,04 GB auf einem Mac, der 29,73 GB als belegt meldete. An einem anderen Tag haben wir es wiederholt: 29,81 gegenüber 26,94.

Bei beiden Messungen liegt die Summe über dem, was der ganze Mac belegt: einmal um 7,3 GB, einmal um 2,9 GB. Kaputt ist nichts. Eine Speicherseite, die sich drei Prozesse teilen, wird dreimal gezählt, und ein Mac teilt sehr viel.

Kaputt ist nichts. Jeder Prozess meldet seinen Footprint, und der zählt jede Speicherseite, die der Prozess berührt. Frameworks, der Cache der gemeinsam genutzten Bibliotheken und komprimierte Seiten werden von vielen Prozessen gleichzeitig berührt, also wird eine Seite, die sich drei Apps teilen, dreimal gezählt. Ein Mac teilt sehr viel, und je mehr Apps geöffnet sind, desto weiter entfernt sich die Summe von der Wirklichkeit.

Was eine App berührt und was zurückkommt

Du kannst fragen, wie viel Arbeitsspeicher eine App berührt oder wie viel zurückkommt, wenn sie beendet wird. Das Erste ist ihr Footprint. Das Zweite ist, um wie viel der belegte Wert, den der Mac selbst angibt, von vorher bis nachher sinkt. Dieser Wert ist kleiner, weil die Seiten, die die App mit etwas anderem geteilt hat, bleiben, wo sie sind.

Jede der beiden Zahlen ist für sich in Ordnung. Das Problem beginnt, wenn ein Satz sie vermischt, und genau das tut eine Menüleiste, die Apps nach Footprint auflistet und dann anbietet, ihre Summe freizugeben. Für eine Auswahl von Apps auf diesem Mac zeigte unsere eigene Menüleiste 10,66 GB zum Freigeben an, ehrlich gerechnet waren es 8,5 GB.

Jetzt verwendet jede Ansicht, die zusagt, wie viel Arbeitsspeicher frei wird, die zweite Zahl. Die Skalierung wird einmal berechnet, über alle Apps, die Mint verfolgt, und nicht über die Auswahl, die eine Ansicht gerade zeigt. Sonst könnten der Tab „Memory“ und die Menüleiste für dieselbe App auf demselben Mac unterschiedliche Antworten geben. Außerdem ist die Kopfzeile einer Gruppe jetzt die Summe der Zeilen darunter. Das klingt selbstverständlich, war aber nicht so: Über Zeilen, die zusammen 14 GB ergaben, stand eine Kopfzeile mit 8 GB.

Der Wert wird nie nach oben skaliert. Was der Mac meldet, ist die Obergrenze, und die Zuordnung senkt eine Zahl nur in Richtung dieser Grenze.

Warum Zusage und Beleg nicht übereinstimmen

Wenn die Einheiten zusammenpassen, kannst du das, was eine Ansicht zugesagt hat, mit dem vergleichen, was tatsächlich passiert ist. Wir haben denselben Prozess mit 2,1 GB dreimal freigegeben und beides gemessen.

Die beiden Werte sollen gar nicht gleich sein. Eine Zusage ist der Anteil einer App unter der Annahme, dass sie so viel teilt, wie es auf diesem Mac im Durchschnitt üblich ist. Ein Beleg ist das, was zurückkam, als genau diese App beendet wurde. Übereinstimmen muss die Einheit.

Sie weichen in beide Richtungen ab, und das ist zu erwarten. Die Zusage ist der Anteil der App unter der Annahme, dass sie so viel teilt, wie es auf diesem Mac im Durchschnitt üblich ist. Der Beleg ist das, was zurückkam, als genau diese App beendet wurde. Eine App mit überwiegend privatem Speicher übertrifft ihre Zusage, eine, die viel geteilt hat, bleibt dahinter zurück. Bevor die Einheiten korrigiert waren, konnte eine Zusage größer sein als der gesamte Arbeitsspeicher, den der Mac belegte, und wenn beide Werte nebeneinanderstehen, ist ein solcher Fehler leicht zu erkennen.

Mit der nächsten Messung des Macs stimmt der Beleg dagegen überein: 1,391 gegenüber 1,406 und 1,989 gegenüber 1,950. Was auf dem Beleg steht, siehst du eine Sekunde später auch am Mac.

Was „Leerlauf“ früher hieß

Die andere Hälfte der Geschichte ist die Frage, welche Zeilen schon angehakt erscheinen. Die alte Regel verlangte, dass eine App groß und gewöhnlich ist, sich gefahrlos auf normalem Weg beenden lässt und im Leerlauf ist. Ob eine App im Leerlauf war, hing davon ab, wann sie zuletzt im Vordergrund war.

Die alte Regel fragte, wann du zuletzt auf etwas geklickt hast. Zwei dieser drei Zeilen arbeiten, während niemand hinsieht, und eine davon galt als das am längsten ruhende Programm auf dem Mac.

So galt ein Terminal, das seit zwei Stunden niemand angeklickt hatte, in dem aber die ganze Zeit ein Agent arbeitete, als das am längsten ruhende Programm auf dem Mac. Die gehosteten Sitzungen von Claude Desktop und die Agent-Prozesse eines Editors wurden auf dieselbe Weise vorab angehakt. Apples eigene Apps kamen aus anderen Gründen nie infrage. Terminal war also zufällig geschützt, jedes Terminal eines Drittanbieters dagegen nicht.

Die naheliegende Lösung wäre gewesen, gar nichts mehr vorab anzuhaken, und die haben wir nicht gewählt. Ein Browser, der 2 GB belegt, während du ihn nicht nutzt, ist genau der Grund, warum es diese Funktion gibt. Ändern musste sich die Frage, die die Regel stellt.

Die neue Regel fragt nach Arbeit und nutzt dafür Signale, die ohnehin schon erfasst wurden. Sie sucht nach einem gehosteten Agenten in der Zeile oder in allem, was die Zeile gestartet hat. Dann prüft sie, ob es im Messzeitraum CPU-Aktivität in der Zeile und allem darunter gab. Zuletzt prüft sie, ob in der App ein Programm unter einer Shell läuft. So sieht ein Terminal, oder das eingebaute Terminal eines Editors, von außen aus.

Eine Zeile, hinter der Arbeit steckt, wird weiterhin aufgeführt, in der Gruppe der Apps in Gebrauch und mit dem Grund daneben, aber Mint hakt sie nicht von sich aus an. Dort steht dann etwa „running Claude Code“ oder „busy · 34 % CPU“, und die Entscheidung liegt bei dir.

Den CPU-Teil richtig hinzubekommen, hat uns einen Nachmittag gekostet. Die CPU-Zeit eines Prozesses kommt in Mach-Ticks zurück, und auf Apple Silicon ist die Umrechnung nicht eins zu eins: Eine Rechenschleife, die wir mit 125,7 ms gemessen hatten, meldete 3.016.253 Ticks. Das Verhältnis musst du beim System erfragen, nicht aus einer Rechnung ableiten, die auf einem Mac zufällig richtig aussieht.

Was wir falsch gemacht haben und wie es sich zeigte

Unsere Demo-Testdaten beschrieben einen Hilfsprozess im Hintergrund mit der Prozess-ID 0.

Der Freigabeweg prüfte, ob der Prozess lief, und schickte ihm dann ein Signal zum Beenden. Unter Unix geht ein Signal an Prozess 0 an die gesamte Prozessgruppe des Aufrufers. Mint beendete sich in 0,66 Sekunden selbst und riss das Shell-Skript mit, das es gestartet hatte. Gemessen haben wir das an einer Kopie, die für solche Tests gebaut war, also war keine echte Sitzung betroffen.

Die Korrektur umfasst drei Zeilen, und herauszufinden, wohin sie gehören, dauerte länger, als sie zu schreiben. Eine Zahl aus Testdaten bleibt eine Zahl, nach der der ausführende Code handelt. Die Prüfung muss also dort sitzen, wo die Aktion passiert, nicht dort, wo die Testdaten geschrieben wurden. Eine Zeile mit einer Prozess-ID von null oder kleiner gilt jetzt als verändert und wird verworfen, die Signalschleife überspringt sie, und ein Test prüft das an genau dieser Stelle. Die Testdaten behalten ihre Null mit Absicht, damit jede künftige Kopie auf diese Schutzprüfung stößt.

Von außen wirken Agenten wie im Leerlauf

Das Terminal in dieser Grafik zeigt, wie ein Entwickler-Mac aussieht, und jeden Monat sehen mehr Macs so aus. Eine Agent-Sitzung kann ein Programm unter einer Shell in einem Terminal sein, ein Hilfsprozess, den ein Editor gestartet hat, oder eine Desktop-App, die eine Coding-Sitzung hostet. Von außen sieht jede davon aus wie eine App, die schon länger niemand angeklickt hat.

Ein Werkzeug für den Arbeitsspeicher muss diesen Fall richtig behandeln, bevor du es bedenkenlos laufen lassen kannst, und deshalb achtet die Regel auf Arbeit statt auf Aufmerksamkeit. Mint führt diese Zeilen auf, sagt, was sie gerade tun, und hakt sie nicht von sich aus an. Du kannst eine davon trotzdem mit einem Klick beenden, wenn du willst. Es passiert aber nicht einfach deshalb, weil du nicht mehr auf das Fenster schaust.

Was wir daraus mitnehmen

Die Rechnung stimmte die ganze Zeit. Beide Zahlen, mit denen wir angefangen haben, waren korrekte Messungen verschiedener Dinge. Der Schaden entstand durch einen Satz, der die eine dorthin setzte, wo die andere hingehörte. Sobald Zusage und Beleg dieselbe Einheit verwenden, kannst du sie hinterher gegeneinander prüfen, statt dich auf das Wort des Werkzeugs zu verlassen.

„Leerlauf“ ist eine Aussage darüber, was ein Mac gerade tut, also sollte man ihn am Mac messen. Die Aufmerksamkeit war das Signal, das sich leicht ablesen ließ, und sie beantwortete eine andere Frage. Die Signale für Arbeit brauchten mehr Code, auch wenn die Daten dahinter schon für etwas anderes erfasst wurden.