[openbeos] Re: Tracker Task Loop

> Could someone please tell me what I can do to keep Tracker Taskloop 
> from spinning out of control and eating up tons of processor
> cycles?  I can't figure out what makes it go crazy, but it can
> literally bring the system to its knees sometimes.

Tracker_taskloop finally started misbehaving again this evening
(50% CPU consumption on one core -- the normal failure mode), and
I had a chance to run the debugger on it.

My findings:

Inside StandAloneTaskLoop::Run(), the "tracker_taskloop" thread is
spinning in some kind of loop, containing calls to the following
functions (not listed in any particular order):

system_time()
snooze_until()
BLocker::Lock()
BLocker::Unlock()
BObjectList<BPrivate::DelayedTask>::CountItems()
ItemAt(long)
RunIfNeeded()

These are in addition to a number of < 0, >= 0, etc. tests.

There are no issues with acquiring the lock -- the spinning occurs
entirely in the thread function (StandAloneTaskLoop::Run()), calling
all of these functions each cycle.

These are the exact same functions which are called when 
tracker_taskloop is operating normally, so it appears to be some
kind of polling thread. I have also seen it call RunWhenIdleTask()
under normal operation, but only once.

From this I would guess that the polling rate-throttle via snooze()
is failing, causing it to start consuming 50% of the CPU time under
some conditions.
(Failure does not appear to be related to system uptime, so it
probably isn't a bigtime_t casting issue).

Note: I'm using cpu_fix here. However, on systems without this
installed, snooze() might be failing completely, leading to a 100%
CPU utilization situation similar to what Dane was describing.

I'm not sure if this problem exists in current versions of Tracker,
and/or whether it also happens under Haiku. The very intermittent
nature of the problem makes this very difficult to answer unless the
system is used full-time.

As nobody has come forward confirming the presence or absence of this
issue in present-day Tracker, I'm assuming it may still be a valid
bug?


- Cyan


---

> I've had a similar issue here for years. It has never been much of
> a problem, because the thread priority is "low" (5) -- even on a
> single-processor machine this doesn't seem to impact system
> responsiveness. Killing Tracker and restarting it stops the spinning.
> It also seems to consume exactly 50% of one CPU, on both a
> single-processor Athlon (1.33GHz) and a quad-core Core2 (2.4GHz),
> which strikes me as very strange.

> The 'FileTypes' application reports OpenTracker as version 5.2.1
> -- it's quite old now, dated around Nov 2003 for all three files.
> This is running under R5+BONE.

> For some reason, it doesn't start spinning until quite some time
> after booting, sometimes many hours. Maybe it only starts spinning
> once something happens, such as performing a certain query, etc.,
> but I haven't managed to trace it to anything yet.

> One potential factor that could be involved is the number of files
> and/or partition size. I suspect in both of our cases we may have
> more files and/or larger partitions than the average BeOS/Haiku user.
> In this case, there's around one million files (which are queried
> several times a day), consuming about 150GB on several BFS 
> partitions, one of which is over 200GB.
> Block size is 2K, and the recommended adjustments to the disk cache
> size (in the kernel settings file) have been made.

> Also, some of the folders contain an unusually large number of files,
> especially the dreaded 'Stuff' folder (over 1000 files).
> Tracker seems to struggle displaying this many items (they "pour"
> into the window over about 10+ seconds, like it's running inside
> a PC emulator on a NES), so maybe one of these could be a trigger.

> Also, I've noticed that occasionally some live queries will stop
> updating; maybe this could be related to the task loop getting
> locked up? It doesn't seem to impact anything else on the system
> though -- hard disk access is still very fast, so it probably isn't
> spinning inside a driver.

> I'll keep an eye on it today to see if I can trace it any further,
> assuming it starts (it hasn't started spinning yet).

> What does this thread actually do?

> - Cyan

----

> Could someone please tell me what I can do to keep Tracker Taskloop 
> from 
> spinning out of control and eating up tons of processor cycles?  I 
> can't 
> figure out what makes it go crazy, but it can literally bring the 
> system 
> to its knees sometimes.  If I use Processcontroller to kill the 
> taskloop, things get nice again right away...and the odd part is that 
> killing taskloop never seems to hurt anything.  But that's using a 
> pail 
> to fix a leaky roof.  I need to figure out what's causing it, or at a 
> bare minimum, find a way to keep auto-killing the thing.
> 
> Suggestions?
> 
> Dane
>

Other related posts: