Cursor: Hohe CPU- oder Speicherlast auf dem Mac: Die beschäftigte Arbeit finden

Cursor kann einen Mac aus mehreren verschiedenen Gründen langsam machen: eine beschäftigte Erweiterung, ein großer Workspace, der verarbeitet wird, eine lang laufende KI-Aufgabe oder ein Prozess, der nach dem Ende der Arbeit weiterhin Speicher verbraucht. Finden Sie zuerst heraus, welche Aktion den Anstieg verursacht. Ein großer Cache-Ordner ist kein Beweis dafür, dass das Löschen die CPU-Auslastung behebt.

Behalten Sie einen reproduzierbaren Vergleich

Speichern Sie das Projekt und notieren Sie die Version von Cursor. Öffnen Sie die Aktivitätsanzeige, suchen Sie nach Cursor und vergleichen Sie CPU und Speicher, bevor Sie das Projekt öffnen, während Sie das Problem reproduzieren und nachdem die Aufgabe beendet ist. Behalten Sie für jeden Test dasselbe Repository und dieselbe Aktion bei.

Wenn sich ein kleiner Ordner normal verhält, ein Monorepo aber nicht, ist der Workspace-Umfang ein nützlicher Anhaltspunkt. Wenn ein neuer Chat reagiert, ein langer Dialog aber nicht, testen Sie das separat. Wenn die Auslastung unter einer wiederholten Last stetig steigt, notieren Sie den Zuwachs und die verstrichene Zeit. Ein einzelner großer Messwert allein belegt kein Speicherleck.

Den Editor von der Arbeit trennen, die er startet

Eine Cursor-Sitzung kann das Editorfenster, Erweiterungen, einen Language Server, Terminals und eine KI-Aufgabe umfassen. Ein Teil dieser Arbeit kann weiterlaufen, während der Editor im Leerlauf ist. Bevor Sie etwas deaktivieren, prüfen Sie, ob in einem Terminal noch ein Build, ein Test-Watcher, ein Entwicklungsserver oder ein Modell läuft. Beenden Sie nur eine Aufgabe, die Sie erkennen, über die normale Steuerung des Terminals oder der Anwendung, nachdem Sie deren Arbeit gespeichert haben.

Vergleichen Sie in der Aktivitätsanzeige den ausgelasteten Prozess an drei Punkten: bei geöffnetem Arbeitsbereich, aber ohne gestartete Aufgabe, während der Aktion, die sich langsam anfühlt, und nachdem diese Aktion abgeschlossen ist. Notieren Sie den Prozessnamen und ob das Symptom eine Eingabeverzögerung, hohe CPU-Last oder steigender Speicherverbrauch ist. Ein Hilfsprozessname allein benennt selten die verantwortliche Erweiterung, daher grenzen Sie die Ursache mit den nächsten Vergleichen ein.

Versuchen Sie, den eigentlichen Projektordner zu öffnen statt dessen übergeordneten Ordner, der mehrere Repositories enthält. Verschieben oder löschen Sie das Projekt für diesen Test nicht. Wenn ein kleinerer Arbeitsbereich das Ergebnis verbessert, stellen Sie fest, was der größere Arbeitsbereich enthielt: generierte Assets, die Abhängigkeiten eines anderen Projekts, einen aktiven Watcher oder ein Sprachwerkzeug, das mehr Dateien durchsucht. Das ist ein Hinweis auf den Umfang, kein Grund, jedes große Verzeichnis auszuschließen.

Beispielsweise kann ein Entwicklungsserver, der wiederholt Ausgaben schreibt, aktive Arbeit sein, die der Editor beobachtet. Ein Ordnerausschluss und das Beenden dieses Servers prüfen unterschiedliche Erklärungen. Ändern Sie beides gleichzeitig, geht die Unterscheidung verloren; notieren Sie daher, welche einzelne Änderung die wiederholte Aktion beeinflusst.

Testen Sie Erweiterungen, bevor Sie den Editor zurücksetzen

Der Leitfaden zur Leistung von Cursor empfiehlt einen Durchlauf mit deaktivierten Erweiterungen. Nachdem Sie Ihre Arbeit gespeichert und Cursor normal beendet haben, starten Sie es im Terminal mit:

cursor --disable-extensions

Dies setzt voraus, dass der Shell-Befehl cursor installiert ist. Falls er nicht verfügbar ist, deaktivieren Sie nicht wesentliche Erweiterungen über die Erweiterungsansicht von Cursor für den Vergleich. Halten Sie fest, was Sie deaktiviert haben, damit der Test umkehrbar bleibt.

Wiederholen Sie dieselbe Projektaktion. Wenn es besser wird, stellen Sie die Erweiterungen eine nach der anderen wieder her, bis das Symptom zurückkehrt. Wenn nicht, stellen Sie den vorherigen Erweiterungszustand wieder her und machen Sie weiter. Behandeln Sie einen Test mit anderen geöffneten Dateien nicht als Beweis gegen eine Erweiterung, und entfernen Sie als nächsten Schritt nicht das gesamte Benutzerdatenverzeichnis.

Einen erfolgreichen Erweiterungstest eingrenzen

Wenn der Lauf mit deaktivierten Erweiterungen dieselbe Aktion verbessert, installieren Sie nicht alle Erweiterungen neu und verwerfen Sie nicht deren Einstellungen. Gehen Sie von der notierten aktivierten Gruppe aus und stellen Sie jeweils eine Erweiterung wieder her, wenn es nur wenige Kandidaten gibt. Bei vielen Erweiterungen können Sie die Gruppe schneller eingrenzen, indem Sie jeweils die Hälfte wiederherstellen, sofern jeder Test dasselbe Projekt öffnet und dieselbe Aktion abschließt.

Die Gruppenmethode ist eine Untersuchungshilfe, kein Beweis dafür, dass genau eine Erweiterung fehlerhaft ist. Zwei Erweiterungen können zusammenwirken, und das Deaktivieren einer Sprach-Erweiterung kann auch Funktionen entfernen, die die Last auslösen. Sobald ein Kandidat auftaucht, wiederholen Sie den Test mit allen Erweiterungen, die Sie tatsächlich benötigen, außer diesem Kandidaten. Prüfen Sie neben der Reaktionsfähigkeit auch Codevervollständigung, Diagnose und den Build.

Wenn der abschließende Vergleich weiterhin auf eine Erweiterung deutet, notieren Sie deren Namen und Version. Ein Deaktivieren nur für den Arbeitsbereich kann geeigneter sein als eine Änderung an jedem Projekt, sofern diese Option vorhanden ist. Wenn das Deaktivieren eine erforderliche Funktion beeinträchtigt, stellen Sie die Erweiterung wieder her und bewahren Sie die Reproduktion für deren Maintainer auf, statt einen schnelleren, aber unvollständigen Editor als gewünschtes Ergebnis zu betrachten.

Schließen Sie generierte Ausgabe aus, die Sie nicht brauchen

KI-gestützte Arbeit kann Build-Ergebnisse, exportierte Bundles, generierte Bilder und große Logs erzeugen. Wenn Sie einen übergeordneten Ordner öffnen, der jedes Projekt enthält, kann das weit mehr Material preisgeben, als die Aufgabe benötigt. Öffnen Sie zuerst das eigentliche Projektverzeichnis.

Cursor dokumentiert .cursorignore, um den KI-Zugriff auf Projektdateien einzuschränken, mit Ausnahmen für Terminal- und MCP-Werkzeuge. Der Leistungsleitfaden empfiehlt, große generierte Ordner auszuschließen. Das geht über eine reine Indexierungsänderung hinaus und stoppt nicht jeden Language-Server oder Dateisystem-Watcher.

Für ein Projekt, in dem diese Verzeichnisse tatsächlich generierte Ausgabe sind, kann eine Datei .cursorignore Folgendes enthalten:

dist/
build/
.next/

Prüfen Sie die Ordner zuerst und behalten Sie bestehende Ignore-Regeln bei. Ein Verzeichnis namens build könnte in Ihrem Projekt manuell gepflegte Build-Skripte enthalten. Das Hinzufügen eines Musters löscht keine Dateien, kann aber nützlichen Kontext aus den KI-Funktionen entfernen. Überprüfen Sie danach den Indexierungszustand und dieselbe Editoraktion erneut.

Verfolgen Sie den Prozess, der noch arbeitet

Der Leitfaden zum Speicherdruck unter Mac erklärt, warum belegter Speicher allein kein verlässlicher Alarm ist. Das Schließen eines ungenutzten Workspace kann einer aktiven Arbeitslast helfen, ohne dessen Inhalte zu löschen.

Prüfen, was ein Ausschluss geändert hat

Prüfen Sie nach einer Änderung an .cursorignore den Dateidiff und testen Sie sowohl die langsame Aktion als auch eine gewöhnliche Frage zu Code, der weiterhin zugänglich sein sollte. Ein kleinerer sichtbarer Projektkontext ist nur nützlich, wenn Cursor noch die für die Aufgabe nötigen Quellen hat. Entfernen Sie nur das neue Muster, wenn es etwas Wichtiges ausgeschlossen hat; ersetzen Sie nicht die gesamte Ignore-Datei durch eine leere.

Halten Sie diese Grenzen getrennt. Git-Ignore-Regeln steuern, wie Git nicht verfolgte Dateien behandelt. Die KI-Zugriffsausschlüsse von Cursor steuern die dokumentierten KI-Funktionen. Ein Language Server, eine Erweiterung oder ein Terminal-Watcher hat sein eigenes Verhalten. Dasselbe Muster überall hinzuzufügen, ohne die ausgelastete Komponente zu identifizieren, kann Symptome verdecken und nützliche Funktionen entfernen.

Wenn die CPU normal ist, aber eine Antwort langsam eintrifft, untersuchen Sie die KI-Anfrage getrennt von der Ressourcennutzung des Editors. Wenn der Speicher bei jeder Wiederholung ansteigt, auch nachdem die Arbeit abgeschlossen ist, notieren Sie mehrere vergleichbare Messwerte und die verstrichenen Intervalle und testen Sie dann, ob ein erneutes Öffnen des Arbeitsbereichs das Muster ändert. Das ist für einen Maintainer weitaus nützlicher, als den höchsten während eines Builds beobachteten Wert zu melden.

Räumen Sie Festplattenreste nur auf, wenn der Speicherplatz das Problem ist

Cursor-Caches, alte Werkzeugversionen, Sitzungsverläufe und Worktrees haben unterschiedliche Besitzer und Anforderungen an die Wiederherstellung. Ein Worktree kann nicht committete Änderungen oder einen Commit enthalten, der nirgendwo sonst existiert. Ein Chatverlauf kann Arbeit sein, die Sie noch brauchen.

Nutzen Sie den Leitfaden zur Bereinigung von KI-Coding-Werkzeugen für diese separate Speicheraufgabe. Bei anhaltenden CPU- oder Speicherproblemen schicken Sie Cursor den kleinsten reproduzierbaren Fall, die Version und den Vergleich der Erweiterungen. Prüfen Sie die Logs, bevor Sie sie teilen, denn sie können Projektnamen oder Code enthalten. So bleibt der Bericht bei der tatsächlichen Verlangsamung und nicht bei einem unzusammenhängenden Bereinigungsergebnis.