Gibt es eine Möglichkeit, den Grund für den Prozess „fseventsd“ zu ermitteln, der die CPU in Mitleidenschaft zieht?

Ich führe Mac OSX 10.6 aus und habe festgestellt, dass ein Prozess „fseventsd“ 100 % CPU und 1,5 GB RAM belegt. Bei einer Google-Suche fand ich heraus, dass dies an Time Machine gebunden sein könnte. Allerdings führe ich Time Machine nicht auf diesem Computer aus.

Gibt es eine Möglichkeit, die Quelle des Ressourcenfressers zu verfolgen? Meldet es sich irgendwo an? Ein Neustart hat das Problem „behoben“, aber ich bin mir sicher, dass es erneut auftreten wird, wenn ich nicht herausfinden kann, warum es überhaupt aufgetreten ist.

Danke im Voraus.

Hast du jemals die Quelle gefunden? Wir haben das gleiche Problem auf unserem Snow-Leopard-Server. Ich kann einen Neustart versuchen, aber das kann ich erst heute Abend tun.
Ich habe es seit meinem Neustart (un)glücklicherweise nicht mehr angezeigt, daher kenne ich die Quelle immer noch nicht
Ich habe das gleiche Problem. Neustart hilft nicht. Nach 20 bis 30 Minuten startet fseventsd erneut, um 99 % der CPU zu beanspruchen. Das Macbook schweigt nicht mehr...

Antworten (2)

fseventd ist der Dateisystem-Ereignisprotokollierungsprozess, Sie können viel darüber in der ars technica-Rezension von Mac OS X Leopard lesen. Sie können Programme wie fseventer verwenden , um die gleiche Art von Ausgabe zu sehen, die es sieht.

Aus dem Artikel:

Das FSEvents-Framework basiert auf einem einzelnen, ständig laufenden Daemon-Prozess namens fseventsd, der aus /dev/fsevents liest und die Ereignisse in Protokolldateien auf der Festplatte schreibt (gespeichert in einem .fseventsd-Verzeichnis im Stammverzeichnis des Volumes, für das die Ereignisse bestimmt sind). Das ist es. Das ist die Super-High-Tech-Lösung: Schreiben Sie einfach die Ereignisse in eine Protokolldatei. Langweilig, pragmatisch, aber durchaus effektiv.

Sie können dieses Protokoll überprüfen, obwohl ich nicht weiß, wie nützlich es für Sie sein wird. Ich wäre nicht so überrascht zu sehen, dass Time Machine, das mit vielen Dateien und manchmal vielen, vielen kleinen Dateien umgeht, möglicherweise einige Probleme mit fsevents verursacht.

Hoffentlich ist es nicht Time Machine, da diese deaktiviert ist! Wie auch immer, ich lese gerade auf fseventer, also danke für den Vorschlag.

Entweder steckte ein Programm in einer sehr effizienten Schleife fest, die Änderungen schrieb, die fseventsdviel Arbeit verursachten, oder es war eine Endlosschleife, die selbst eine nicht auflösbare Datenstruktur auf einem der gemounteten Volumes verarbeitete.

Im vorherigen Fall – Programme wie fseventer, die denselben Datenstrom lesen, werden wahrscheinlich ebenfalls hängen bleiben – haben Sie jetzt zwei Prozesse mit einer Auslastung von 50 %, die versuchen, eine unendliche Datenmenge zu verarbeiten. (Dies ist ein großartiger Datenpunkt, wenn Sie nachsehen möchten, was nicht stimmt.) Es ist analog zu Fragen, die fragen, warum syslogddie gesamte CPU beansprucht wird - normalerweise ist es ein anderes Programm, das verrückt geworden ist und viel Arbeit verursacht.

Wenn/falls es wieder vorkommt – beginnen Sie mit dem Beenden von Programmen und erwägen Sie, sich abzumelden. Sie wissen, ob das anstößige Element ein Prozess auf Systemebene oder ein Prozess auf Benutzerebene ist. fs_usagekönnte nützlich sein, um zu sehen, welche spezifischen Programme IO-lastig sind.

fsckvon einem Start in den Einzelbenutzermodus ist normalerweise erforderlich, wenn Sie zirkuläre Hardlinks oder andere degenerierte Dateisystem-Spielereien haben, die diese Art von Aktivitätsspitzen verursachen können.

Ja, tut mir leid, wenn ich mich unklar ausgedrückt habe, Sie konnten Fseventer definitiv nicht öffnen, während die Poop sprichwörtlich den Lüfter traf. Ich wollte Ihnen nur einen Eindruck davon vermitteln, welche Art von Daten protokolliert und angezeigt werden, wie es fs_usage tun würde.
Ich habe es geliebt, etwas über Fseventer zu lernen - sieht sehr gut aus. Es gibt keinen Fehler – nur Daten.
Wow, danke für den Tipp zu 'fs_usage'. Und ja, ich dachte, es war nicht wirklich fseventsd, das die Last verursacht, sondern ein anderes Programm. Ich erwarte irgendwo eine Schleife. Abgesehen davon läuft die Maschine seit etwa 24 Stunden unter normaler Last, und es ist nicht wieder passiert.