15

I run Mac OSX 10.6 and noticed that a process 'fseventsd' was taking 100% CPU and 1.5G RAM. Doing a google search, I found that this could be tied to Time Machine. However, I do not run Time Machine on this computer.

Is there a way to trace the source of the resource hog? Does it log to anywhere? A restart 'fixed' the issue, but I'm sure it will come back if I can't figure out why it began in the first place.

Thanks in advance.

Derek Downey
  • 259
  • Did you ever find the source? We're experiencing the same issue on our snow leopard server. I may try a reboot but I can't do that until later tonight. – Greg W May 09 '11 at 19:19
  • I have not had it pop up since my reboot, (un)fortunately, so I still don't know the source – Derek Downey May 09 '11 at 21:56
  • I have the same problem. Rebooting doesn't help. After 20 to 30 minutes, fseventsd starts again to take 99% CPU. The Macbook is not silent anymore... – Laurent K Apr 25 '13 at 21:30

2 Answers2

7

fseventd is the filesystem event logging process, you can read a lot about it in the ars technica review of Mac OS X Leopard. You can use programs like fseventer to see the same kind of output it sees.

From the article:

The FSEvents framework relies on a single, constantly running daemon process called fseventsd that reads from /dev/fsevents and writes the events to log files on disk (stored in a .fseventsd directory at the root of the volume the events are for). That's it. That's the super-high-tech solution: just write the events to a log file. Boring, pragmatic, but quite effective.

You can check that log though I dont know how useful it will be for you. I would not be that surprised to see Time Machine, which deals with many files, and sometimes many many tiny files, to possibly cause some issues with fsevents.

ConstantineK
  • 5,722
  • Hopefully it's not Time Machine, since this is disabled! Anyway, I'm reading up on fseventer, so thanks for the suggestion. – Derek Downey Apr 29 '11 at 16:42
3

Either one program was stuck in a very efficient loop writing changes that caused fseventsd to have a lot of work or it's an infinite loop itself processing an unresolvable data structure on one of the mounted volumes.

In the prior case - programs like fseventer that read the same stream of data will likely hang as well - you'll now have two processes at 50% utilization trying to process an infinite amount of data. (This is a great data point if you are poking to see what's amiss.) It's analagous to questions asking why syslogd is taking all the CPU - usually it's some other program gone nuts causing it a lot of work.

When/if it happens again - start quitting programs and consider logging out. You will know if the offending item is a system level process or a user level process. fs_usage might be useful to see what specific programs are IO heavy.

fsck from a boot into single user mode is usually required if you have circular hard links or other degenerate file system shenanigans that can cause this sort of spike in activity.

bmike
  • 235,889
  • Yeah, sorry if I was being unclear, you definitely could not open fseventer while the poop proverbially hit the fan. I just meant more to give you an inkling into what kind of data was logged and viewable, as fs_usage would. – ConstantineK Apr 28 '11 at 18:39
  • I loved learning about fseventer - look very nice. There is no failure - just data. – bmike Apr 28 '11 at 19:25
  • Wow, thanks for the tip on 'fs_usage'. And yeah, I figured it wasn't actually fseventsd causing the load, but rather some other program. I expect a loop somewhere. As an aside, machine has been running normal load for 24 hours or so, and it hasn't happened again. – Derek Downey Apr 29 '11 at 16:41