Futtattam a Mac OSX 10.6-ot, és észrevettem, hogy az “fseventsd” folyamat 100% -os CPU-t és 1,5 G RAM-ot foglal el. A Google keresése során megállapítottam, hogy ez a Time Machine-hez köthető. Azonban nem futtatom a Time Machine-et ezen a számítógépen.

Van-e mód az erőforrás-disznó forrásának felkutatására? Bejelentkezik bárhová? Az újraindítás “megoldotta” a problémát, de biztos vagyok benne, hogy visszatér, ha nem tudom kideríteni, hogy miért is kezdődött.

Előre is köszönöm.

Megjegyzések

  • Megtalálta valaha a forrást? ' ugyanazt a problémát tapasztaljuk a hóleopárd szerverünkön. Lehet, hogy megpróbálok újraindítani, de ' ezt nem tehetem meg később este.
  • Az újraindítás óta nem jelenik meg, (szerencsére), így még mindig nem ' nem ismerem a forrást
  • Ugyanez a problémám. Az újraindítás nem segít '. 20-30 perc elteltével az fseventsd újrakezdi a 99% -os CPU-t. A Macbook már nem hallgat …

Válasz

Az fseventd a fájlrendszer eseménynaplózási folyamata, sokat olvashattunk róla a Mac OS X Leopard ars technica áttekintésében. Használhatja a fseventer programokhoz hasonló típusú kimenetet.

A cikkből:

Az FSEvents keretrendszer egyetlen, folyamatosan futó démon folyamatra támaszkodik, az fseventsd nevűre, amely a / dev / fsevents könyvtárból olvas és írja az eseményeket a lemezen lévő fájlokba (amelyek egy .fseventsd könyvtárban vannak tárolva) az eseményeknek szóló kötet gyökere). Ez az. Ez a szuper-high-tech megoldás: csak írja be az eseményeket egy naplófájlba. Unalmas, pragmatikus, de meglehetősen hatékony.

Ellenőrizheti a naplót, bár nem tudom, mennyire hasznos lesz az Ön számára. Nem lennék meglepve, ha látnám, hogy a Time Machine, amely sok fájllal, és néha sok apró fájllal foglalkozik, esetleg problémákat okozhat az fsevents-ben.

Megjegyzések

  • Remélhetőleg ' ez nem az Időgép, mivel ez le van tiltva! Egyébként ' olvasok az fseventeren, ezért köszönöm a javaslatot.

Válasz

Vagy az egyik program nagyon elakadt a ciklusírás változásaiban, amelyek miatt fseventsd sok munkát végzett, vagy egy végtelen ciklus maga dolgozott fel egy megoldhatatlan adatstruktúra az egyik csatlakoztatott köteten.

Korábbi esetben – valószínűleg az ugyanazt az adatfolyamot olvasó fseventer programok is lógnak – most két folyamat lesz 50% -os kihasználással hogy végtelen mennyiségű adatot dolgozzon fel. (Ez egy nagyszerű adatpont, ha piszkálod, hogy mi nem megfelelő.) Hasonló a kérdésekre, amikor azt kérdezik, hogy syslogd miért veszi el az összes CPU-t – általában ez az egyik más program eldőlt, ami sok munkát okozott neki.

Mikor / ha ismétlődik – kezdje el a programok bezárását és fontolja meg a kijelentkezést. Tudni fogja, hogy a sértő elem rendszerszintű vagy felhasználói szintű folyamat-e. A fs_usage hasznos lehet annak megtekintéséhez, hogy milyen konkrét programok nehezek az IO-ra.

fsck rendszerindítóból egyetlen felhasználóvá módra általában akkor van szükség, ha körkörös merevlemezekkel vagy más degenerált fájlrendszerrel rendelkezik, amelyek ilyen jellegű spike-ot okozhatnak.

Megjegyzések

  • Igen Sajnálom, ha nem voltam világos, akkor biztosan nem tudta megnyitni az fseventert, miközben a kaki közmondásosan eltalálta a ventilátort. Csak arra gondoltam, hogy többet tudjak adni arról, hogy milyen adatok vannak naplózva és megtekinthetők, ahogy az fs_usage megtenné. li> Szerettem abo-t tanulni ut fseventer – nagyon szépen néz ki. Nincs hiba – csak adatok.
  • Hú, köszönöm a tippet a ' fs_usage ' címre. És igen, úgy gondoltam, hogy nem ' nem fseventsd okozta a terhelést, hanem valami más program. Valahol hurokra számítok. Egyébként a gép körülbelül 24 órája normál terhelést hajtott végre, és ez nem történt meg újra.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük