Monterey 12.0-12.5 - Finder benötigt fast gesamte CPU

S

stekarch

Aktives Mitglied
Thread Starter
Dabei seit
29.12.2003
Beiträge
310
Reaktionspunkte
15
Dass es da Monterey Probleme mit dem Finder gibt, habe ich wohl verstanden. Allerdings haben wir den sechs Monaten mit Monterey ein spezielles Problem, dass die tägliche Arbeit wirklich stört: Der Finder reagiert verzögert und benötigt auch für einfache Aufträge wie Verschieben oder Löschen sehr lange (10-20 Sekunden). Außerdem lastet er die CPU oftmals fast vollständig aus (s. Anhang), was die Verzögerung auch begründen kann. Mehrmals am Tag müssen wir den Finder neu starten, weil gar nichts mehr geht.

Was wir suchen, ist ein Workaround, um das Problem entweder ganz zu umgehen oder mindestens zu entschärfen.

Daten: iMac Late 2015 (Intel!), 16 GB, iCloud Drive 2 TB, Monterey 12.5, TM auf externe HD (6 TB), über USB 3.0 angeschlossen
 

Anhänge

  • Bildschirmfoto 2022-08-05 um 08.21.15.png
    Bildschirmfoto 2022-08-05 um 08.21.15.png
    305,1 KB · Aufrufe: 86
Hast du eventuell irgendwelche Finder-Erweiterungen aktiv? Keines unserer Geräte hier hat dieses Problem.

Apfel -> Systemeinstellungen -> Erweiterungen -> Finder-Erweiterungen
 

Anhänge

  • Bildschirmfoto 2022-08-05 um 08.28.11.png
    Bildschirmfoto 2022-08-05 um 08.28.11.png
    181,9 KB · Aufrufe: 80
Meinst du mit iCloud Drive das Fusion Drive? Wie stark ist denn die interne Platte belegt? Wie sieht bei dem Verhalten der Swap aus? Also das die Geräte mit FusionDrive teilweise lahm sind, ist bei den neuesten MacOS Versionen ja häufig der Fall. Das ganze APFS ist halt echt auf Verwendung mit schnellem Speicher ausgelegt.
 
Zuletzt bearbeitet:
Finder-Erweiterungen: OneDrive und Dropbox-Finder-Integration.

Habe die Häkchen gerade mal entfernt…
 
Ach ja, vielleicht kannst du auch mal die SMART Werte der Festplatte (mit einem geeigneten Tool) auslesen. Kann natürlich auch eine sterbende Festplatte sein. Da gibt es ja viele Tools (DriveX,…). Da werden dann auch nicht nur die einfachen SMART Werte gelesen, sondern das Laufwerk auch noch mal geprüft.
 
Was den Finder gerne mal ausbremst sind externe Platten im Schlafmodus. Da wird dann bei Dateioperationen gewartet bis diese aufgewacht sind - selbst wenn man gar nicht auf die externe Platte zugreifen möchte.
Die hohen Auslastungswerte bei den OpenAndSavePanelServices könnten ein Indikator dafür sein...
 
Zuletzt bearbeitet:
Also appkit xpc openAndSavePanel hat doch nichts mit dem Finder zu tun.
AppKit ist eine grundlegende API, xpc Kommunikation zwischen Prozessen.
Die Bug scheint also eher tiefer liegend zu sein.
 
  • Gefällt mir
Reaktionen: SirVikon
Also appkit xpc openAndSavePanel hat doch nichts mit dem Finder zu tun.
Korrekt und wie man aus dem Screenshot sieht läuft da mal wieder ein Safari Amok, also nix dramatisches. Ist wohl mal Zeit da den Safari-Cache von einigem Gerümpel zu befreien ... Speicher-Runaways in WebKit sind ja nun keine Seltenheit.
 
  • Gefällt mir
Reaktionen: dg2rbf
Schon einen anderen Dateimanager getestet, ob der dasselbe Verhalten zeigt?
 
  • Gefällt mir
Reaktionen: dg2rbf
Also, ich bin etwas weitergekommen: Ich habe den iMac im Wiederherstellungsmodus gestartet und das Festplattendienstprogramm über das Volumen und beide Bereiche der Festplatte laufen lassen, und siehe da - der Datenteil hat einen Fehler, der nicht repariert werden kann. Empfehlung: Löschen der HD und Wiederherstellung über TM. Dafür fehlt mir aber noch der Mut... Kann man sich auf die Wiederherstellung aus einer TM inkl. aller Dateien verlassen?
 
Also, ich bin etwas weitergekommen: Ich habe den iMac im Wiederherstellungsmodus gestartet und das Festplattendienstprogramm über das Volumen und beide Bereiche der Festplatte laufen lassen, und siehe da - der Datenteil hat einen Fehler, der nicht repariert werden kann. Empfehlung: Löschen der HD und Wiederherstellung über TM. Dafür fehlt mir aber noch der Mut... Kann man sich auf die Wiederherstellung aus einer TM inkl. aller Dateien verlassen?
Zeig mal einen Screenshot der Meldung, nicht alle sogenannten Fehler sind auch welche oder schreien gleich nach platt machen.
 
Das fehlte noch:
 

Anhänge

  • Bildschirmfoto 2022-08-05 um 21.47.54.png
    Bildschirmfoto 2022-08-05 um 21.47.54.png
    154,7 KB · Aufrufe: 102
Du solltest die Prüfung, wie es da steht, zuerst mal auf den gesamten Container und nicht auf das Volume ausführen. Exit-Code 8 heisst nur dass die Prüfung da nicht weiter kommt weil Zugriffsrechte nicht vollständig sind.
 
Hi,
Würde zuerst in die Recovery booten, und von dort aus die Reperatur via Festplattendienstprogramm ausführen.
LG Franz
 
Zuletzt bearbeitet:
Prüfung des Containers - natürlich wie gewünscht...:

Code:
Erste Hilfe auf „Container disk2“ ausführen

Während das Startvolume überprüft wird, reagiert der Computer nicht.

Speichersystem überprüfen
Livemodus verwenden.
fsck_apfs -n -x -l /dev/disk1s2 ausführen
Den Container-Superblock prüfen …
Den Fusion-Superblock prüfen …
Den EFI-Jumpstart-Eintrag prüfen …
Den Space-Manager prüfen …
Die Space-Manager-Free-Queue-Bäume prüfen …
Die Objektzuordnung prüfen …
Die Fusion-Datenstrukturen prüfen …
Die Strukturen des Verschlüsselungsschlüssels prüfen …
Volume „/dev/rdisk2s1“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Schnappschuss 1 von 2 (com.apple.TimeMachine.2022-08-05-103046.local) prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
warning: snapshot fsroot / file key rolling / doc-id tree corruptions are not repaired; they'll go away once the snapshot is deleted
warning: bitmap store: reached limit of 23040 B-tree nodes
Schnappschuss 2 von 2 (com.apple.TimeMachine.2022-08-05-204129.local) prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
Den Dokument-ID-Baum prüfen …
Den Fsroot-Baum prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s1“ ist offenbar beschädigt und muss repariert werden.
Volume „/dev/rdisk2s2“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
warning: found orphan xattr (id 786499, name com.dropbox.attributes)
warning: found orphan xattr (id 1245267, name com.apple.cpl.original)
warning: found orphan xattr (id 1245267, name com.apple.quarantine)
warning: found orphan xattr (id 1245283, name com.apple.cpl.original)
warning: found orphan xattr (id 1245283, name com.apple.quarantine)
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s2“ ist offenbar beschädigt und muss repariert werden.
Volume „/dev/rdisk2s3“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s3“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s4“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s4“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s5“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Schnappschuss 1 von 1 (com.apple.os.update-0804E5018817E567FAE937224935325B45A1F8395357758797A05E3214E239D9) prüfen …
Den Fsroot-Baum prüfen …
Den File-Extent-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s5“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s6“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s6“ ist anscheinend in Ordnung.
Zugeordneten Platz überprüfen …
Verschobene Reparaturen durchführen …
error: Unable to perform deferred repairs without full space verification
Der Container „/dev/disk1s2“ konnte nicht vollständig überprüft werden.
Exit-Code für Speichersystemprüfung lautet 8.
Das Überprüfen oder Reparieren des Speichersystems ist fehlgeschlagen. : (-69716)

Vorgang erfolgreich.
 
Zuletzt bearbeitet von einem Moderator:
Schmeiss mal erstmal die beiden kaputten TM Snapshots über tmutils raus und lass noch mal laufen. Da hat sich offenbar ein Sync Fehler eingeschlichen als die Dropbox und TM gleichzeitig laufen wollten. Hattest du die Updates auf dem Dropbox Client nicht immer gleich gemacht?
 
  • Gefällt mir
Reaktionen: dg2rbf
Das Gleiche nochmal aus dem Recovery-Mode heraus...
 

Anhänge

  • tempImageUYJ5v5.png
    tempImageUYJ5v5.png
    896,2 KB · Aufrufe: 56
Habe die beiden "kaputten" Snapshot rausgeworfen und siehe da: Die folgenden werden auch als kaputt identifiziert. Was tun?

--------------------------------------------------------------------------------------------------------------------------------------------------
Code:
Erste Hilfe auf „Container disk2“ ausführen

Während das Startvolume überprüft wird, reagiert der Computer nicht.

Speichersystem überprüfen
Livemodus verwenden.
fsck_apfs -n -x -l /dev/disk1s2 ausführen
Den Container-Superblock prüfen …
Den Fusion-Superblock prüfen …
Den EFI-Jumpstart-Eintrag prüfen …
Den Space-Manager prüfen …
Die Space-Manager-Free-Queue-Bäume prüfen …
Die Objektzuordnung prüfen …
Die Fusion-Datenstrukturen prüfen …
Die Strukturen des Verschlüsselungsschlüssels prüfen …
Volume „/dev/rdisk2s1“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Schnappschuss 1 von 3 (com.apple.TimeMachine.2022-08-05-231151.local) prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
warning: snapshot fsroot / file key rolling / doc-id tree corruptions are not repaired; they'll go away once the snapshot is deleted
warning: bitmap store: reached limit of 23040 B-tree nodes
Schnappschuss 2 von 3 (com.apple.TimeMachine.2022-08-06-021226.local) prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
Schnappschuss 3 von 3 (com.apple.TimeMachine.2022-08-06-042818.local) prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
Den Dokument-ID-Baum prüfen …
Den Fsroot-Baum prüfen …
error: doc-id tree: record exists for doc-id 242921, file-id 13731258651 but no inode references this doc-id
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s1“ ist offenbar beschädigt und muss repariert werden.
Volume „/dev/rdisk2s2“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
warning: found orphan xattr (id 786499, name com.dropbox.attributes)
warning: found orphan xattr (id 1245267, name com.apple.cpl.original)
warning: found orphan xattr (id 1245267, name com.apple.quarantine)
warning: found orphan xattr (id 1245283, name com.apple.cpl.original)
warning: found orphan xattr (id 1245283, name com.apple.quarantine)
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s2“ ist offenbar beschädigt und muss repariert werden.
Volume „/dev/rdisk2s3“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s3“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s4“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s4“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s5“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Schnappschuss 1 von 1 (com.apple.os.update-0804E5018817E567FAE937224935325B45A1F8395357758797A05E3214E239D9) prüfen …
Den Fsroot-Baum prüfen …
Den File-Extent-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s5“ ist anscheinend in Ordnung.
Volume „/dev/rdisk2s6“ wird überprüft.
Den APFS-Volume-Superblock prüfen …
Die Objektzuordnung prüfen …
Den Schnappschuss-Metadatenbaum prüfen …
Die Schnappschuss-Metadaten prüfen …
Den Fsroot-Baum prüfen …
Den Extent-Ref-Baum prüfen …
Den Object-Map-Platz des Volumes prüfen …
Das Volume „/dev/rdisk2s6“ ist anscheinend in Ordnung.
Zugeordneten Platz überprüfen …
Verschobene Reparaturen durchführen …
error: Unable to perform deferred repairs without full space verification
Der Container „/dev/disk1s2“ konnte nicht vollständig überprüft werden.
Exit-Code für Speichersystemprüfung lautet 8.
Das Überprüfen oder Reparieren des Speichersystems ist fehlgeschlagen. : (-69716)

Vorgang erfolgreich.
 
Zuletzt bearbeitet von einem Moderator:
Lösch halt die defekten Snapshots, das geht ja auch im FPDP bei Monterey.
 
Ja, aber es scheinen ja, alle defekt zu sein, oder? Immer wenn ich welche lösche, werden die folgenden wieder als defekt bezeichnet. Das Finder-Problem habe ich ja schon mehrere Monate!
 
Zurück
Oben Unten