Jeg kører Mac OSX 10.6 og bemærkede, at en proces “fseventsd” tog 100% CPU og 1,5 G RAM. Ved at foretage en google-søgning fandt jeg ud af, at dette kunne knyttes til Time Machine. Jeg kører dog ikke Time Machine på denne computer.
Er der en måde at spore kilden til ressourcehoggen på? Logger den overalt? En genstart “fikset” problemet, men jeg er sikker på, at det vil komme tilbage, hvis jeg ikke kan finde ud af, hvorfor det startede i første omgang.
Tak på forhånd.
Kommentarer
- Fandt du nogensinde kilden? Vi ' oplever det samme problem på vores snow leopard-server. Jeg kan prøve en genstart, men jeg kan ' ikke gøre det indtil senere i aften.
- Jeg har ikke fået det til at dukke op siden min genstart, (u) heldigvis, så jeg kender stadig ikke ' kilden
- Jeg har det samme problem. Genstart ' hjælper ikke. Efter 20 til 30 minutter begynder fseventsd igen at tage 99% CPU. Macbook er ikke tavs længere …
Svar
fseventd er filsystemets hændelseslogningsproces, du kan læse meget om det i ars technica-gennemgangen af Mac OS X Leopard. Du kan bruge programmer som fseventer for at se den samme type output, som den ser.
Fra artiklen:
FSEvents-rammen er afhængig af en enkelt, konstant kørende dæmonproces kaldet fseventsd, der læser fra / dev / fsevents og skriver begivenhederne til logfiler på disken (gemt i et .fseventsd-bibliotek på roden til det volumen, begivenhederne er beregnet til). Det er det. Det er den superhøjteknologiske løsning: skriv begivenhederne til en logfil. Kedeligt, pragmatisk, men ret effektivt.
Du kan kontrollere loggen, selvom jeg ikke ved, hvor nyttig den vil være for dig. Jeg ville ikke være så overrasket over at se Time Machine, der beskæftiger sig med mange filer og nogle gange mange mange små filer, muligvis forårsager nogle problemer med fsevents.
Kommentarer
- Forhåbentlig er det ' ikke Time Machine, da dette er deaktiveret! Under alle omstændigheder læser jeg ' på fseventer, så tak for forslaget.
Svar
Enten sidder et program fast i en meget effektiv loop-skrivning af ændringer, der får fseventsd til at have meget arbejde, eller det er en uendelig løkke, der selv behandler en uløselig datastruktur på en af de monterede diskenheder.
I det tidligere tilfælde – programmer som fseventer, der læser den samme strøm af data, vil sandsynligvis også hænge – du har nu to processer ved 50% udnyttelse til at behandle en uendelig mængde data. (Dette er et fantastisk datapunkt, hvis du pokker for at se, hvad der er galt.) Det er analogt med spørgsmål, der spørger, hvorfor syslogd tager al CPU – normalt er det noget andet program er blevet nødt til at forårsage meget arbejde.
Når / hvis det sker igen – start afslutning af programmer og overvej at logge ud. Du ved, om det fornærmende emne er en proces på systemniveau eller en brugerniveauproces . fs_usage kan være nyttigt at se, hvilke specifikke programmer der er IO-tunge.
fsck fra en boot til en enkelt bruger tilstand er normalt påkrævet, hvis du har cirkulære hårde links eller andre degenererede filsystem-shenanigans, der kan forårsage denne slags stigning i aktivitet.
Kommentarer
- Ja , undskyld, hvis jeg var uklar, kunne du bestemt ikke åbne fseventer, mens poppen ordsprog ramte fanen. Jeg mente bare mere for at give dig et indblik i, hvilken slags data der var logget og synlig, som fs_usage ville.
- Jeg elskede at lære abo ut fseventer – se meget flot ud. Der er ingen fejl – bare data.
- Wow, tak for tipet til ' fs_usage '. Og ja, jeg regnede med, at det ikke ' faktisk ikke forårsagede belastningen, men snarere et andet program. Jeg forventer en løkke et eller andet sted. Som en bortset fra har maskinen kørt normal belastning i cirka 24 timer, og den har ikke ' t sket igen.