Ik draai Mac OSX 10.6 en merkte dat een proces “fseventsd” 100% CPU en 1.5G RAM in beslag nam. Toen ik een Google-zoekopdracht deed, ontdekte ik dat dit te maken had met Time Machine. Ik draai Time Machine echter niet op deze computer.
Is er een manier om de bron van het bronvarken te achterhalen? Logt het ergens in? Een herstart “loste” het probleem op, maar ik “weet zeker dat het terug zal komen als ik er niet achter kan komen waarom het in de eerste plaats begon.
Bij voorbaat dank.
Opmerkingen
- Heb je ooit de bron gevonden? We ' ondervinden hetzelfde probleem op onze Snow Leopard-server. Ik zou kunnen proberen om opnieuw op te starten, maar ik kan ' dat pas later vanavond doen.
- Ik heb het niet meer zien verschijnen sinds mijn herstart, (on) gelukkig, dus ik weet nog steeds niet ' de bron
- Ik heb hetzelfde probleem. Opnieuw opstarten helpt niet '. Na 20 tot 30 minuten begint fseventsd opnieuw om 99% CPU in beslag te nemen. De Macbook is niet meer stil …
Antwoord
fseventd is het logboekproces van het bestandssysteem, je kunt lees er veel over in de ars technica-recensie van Mac OS X Leopard. U kunt programmas zoals fseventer gebruiken om dezelfde soort output te zien die het ziet.
Uit het artikel:
Het FSEvents-framework vertrouwt op een enkel, constant draaiend daemon-proces genaamd fseventsd dat leest van / dev / fsevents en de gebeurtenissen naar logbestanden op schijf schrijft (opgeslagen in een .fseventsd-map op de root van het volume waarvoor de gebeurtenissen zijn bedoeld). Dat is het. Dat is de super high-tech oplossing: schrijf de gebeurtenissen gewoon naar een logbestand. Saai, pragmatisch, maar behoorlijk effectief.
U kunt dat logboek controleren, hoewel ik niet weet hoe nuttig het voor u zal zijn. Ik zou niet zo verbaasd zijn om te zien dat Time Machine, dat veel bestanden behandelt, en soms veel kleine bestanden, mogelijk problemen veroorzaakt met fsevents.
Opmerkingen
- Hopelijk is het ' niet Time Machine, aangezien dit is uitgeschakeld! Hoe dan ook, ik ' ben aan het lezen op fseventer, dus bedankt voor de suggestie.
Antwoord
Een van beide programmas zat vast in een zeer efficiënte lusschrijfveranderingen die ervoor zorgden dat fseventsd veel werk had of het is een oneindige lus die zelf een onoplosbare datastructuur op een van de gekoppelde volumes.
In het vorige geval – programmas zoals fseventer die dezelfde gegevensstroom lezen, zullen waarschijnlijk ook vastlopen – zul je nu twee processen proberen met een bezettingsgraad van 50%. om een oneindige hoeveelheid gegevens te verwerken. (Dit is een geweldig gegevenspunt als je aan het porren bent om te zien wat er mis is.) Het is analoog aan vragen die stellen waarom syslogd de hele CPU in beslag neemt – meestal is het wat ander programma werd gek waardoor het veel werk veroorzaakte.
Wanneer / als het opnieuw gebeurt – begin met het afsluiten van programmas en overweeg uit te loggen. U zult weten of het aanstootgevende item een proces op systeemniveau of een proces op gebruikersniveau is . fs_usage kan handig zijn om te zien welke specifieke programmas IO-zwaar zijn.
fsck van opstarten naar enkele gebruiker modus is meestal vereist als je cirkelvormige harde koppelingen hebt of andere gedegenereerde streken van het bestandssysteem die dit soort piek in activiteit kunnen veroorzaken.
Reacties
- Ja , sorry als ik onduidelijk was, je kon fseventer zeker niet openen terwijl de poep spreekwoordelijk de ventilator raakte. Ik bedoelde alleen meer om je een idee te geven van wat voor soort gegevens er waren gelogd en zichtbaar, zoals fs_usage zou doen.
- Ik vond het geweldig om abo te leren ut fseventer – ziet er erg mooi uit. Er is geen fout – alleen gegevens.
- Wauw, bedankt voor de tip over ' fs_usage '. En ja, ik dacht dat het niet ' t eigenlijk fseventsd was die de belasting veroorzaakte, maar eerder een ander programma. Ik verwacht ergens een lus. Even terzijde: de machine draait al ongeveer 24 uur normaal, en het is niet ' nog eens gebeurd.