Tracker consumes more then 90% of CPU even when indexing is disabled

I've killed trackerd (SIGKILL, as SIGTERM doesn't work), so I don't know what tracker-status would've told me.. but I told tracker not to index or watch, so it shouldn't be doing any of these things (I don't think it should even start if both are disabled, it's kind of pointless to have it running when it hasn't indexed anything)

Can someone set the priority for bug to critical

we will fix this soon... (I dont have permission to change priority)

Fixed in svn (option is not live yet though so will only take effect when tracker is restarted - will make options live very soon)

Jamie is releasing 0.6.3 this week (possibly on 20th). I'll take care of packaging it.

Retargeting as this won't make Beta release. We will upload a new tracker release with a fix for this right after beta release, when the freeze isn't in place anymore.

tracker (0.6.3-0ubuntu1) gutsy; urgency=low

  [ Emilio Pozuelo Monfort ]
  * New upstream release (LP: #130794, #131983, #132320, #137352, #138331,
    #139173, #132505, #131559, #131735, #132710, #133246, #137873, #138778.
  * debian/patches/01-version_fix.patch,
    debian/patches/02-getenv.patch,
    - Removed, fixed upstream.
  * debian/patches/03-system_ioprio.patch: not needed anymore, as tracker
    now tries ioprio system syscalls if available.
  * debian/patches/01_from_upstream_fix_stemming.patch:
    - Added, fixes language selection.

  [ Martin Pitt ]
  * debian/control: Promote o3read to a dependency. That way, updates will get
    it, too, and we avoid making it a dependency of ubuntu-desktop. With the
    external dependency we can avoid installing the internal code copy.

 -- Martin Pitt <email address hidden> Fri, 28 Sep 2007 17:45:16 +0200

Trackerd consumes a lot of CPU mainly when I'm downloading something. I notice it most obviously when using KTorrent. It's as if trackerd sees the change to some blocks of the file and has to rescan the whole thing, over and over again. Since the file is continually modified, as long as anything is downloading, trackerd will grab 100% of my CPU. This happens on desktops, laptops, even while on battery. It is a major problem.

I had a similar problem this afternoon. tracker was using up between 40-48% of the cpu power, and was slowly the system down very visibly. After adjusting tracker-settings for lower cpu usage, the problem seemed to be alleviated. A check at the tracker log showed showed a huge stream of errors for a several minute period, caused by files / directories in my home directory that were owned by root, e.g.
"31 Oct 2007, 12:57:48:541 - ERROR: Inotify watch on /home/hughitt1/reconstructor_i386/root/usr/share/pixmaps/amsn has failed"

Hope this help.
Take care,
Keith

The problem still persists on my machine with the latest updates, why is the status fixed released?

Running trackerd 0.6.3 with indexing and watching enabled at throttle level 20, it gets stuck and uses ~90% of one core perhaps a minute or two after launching. strace shows the following output:

poll([{fd=11, events=POLLIN}, {fd=16, events=POLLIN}, {fd=13, events=POLLIN}], 3, 1998) = 0
gettimeofday({1196449076, 947962}, NULL) = 0
open("/proc/acpi/ac_adapter/ACAD/state", O_RDONLY|O_LARGEFILE) = 33
fstat64(33, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
fcntl64(33, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(33, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb63de000
_llseek(33, 0, [0], SEEK_CUR) = 0
read(33, "state: on-line"..., 4096) = 33
read(33, "", 3072) = 0
close(33) = 0
munmap(0xb63de000, 4096) = 0
gettimeofday({1196449076, 949136}, NULL) = 0

repeated about every 2 seconds.

i have a new installation with 8.04 hardy: same problem:
tracker consumes all cpu (despite saying it is in state 'sleeping').
this is after the system was sitting idle for a day, thus all available files should have been indexed.

please fix, or make it at least not default setting: it is a huge disappointment for somebody not knowledgeable installing ubuntu and find it SOOOOO SLOW, only because of tracker (which is not terribly useful, missing a more selective search function).

thank you for (otherwise) a nice system!
andrew

if trackerd is not shut down cleanly it will call sqlite to do a corruption check.

This corruption check is very cpu heavy and Im thinking about removing it due to the load it causes.

For me, tracker crashes at least daily on hardy, but maybe that's because it's still alpha. Tracker is definitely a net-minus for daily use in hardy right now, will probably just uninstall it at some point if it doesn't stabilize. Most of the time when I try to actually use it, it doesn't work anyway, so the constant drag on the hard drive is not worth it.

Thom,

have you reported the crashes in trackerd? (crashes in tracker-extract are irrelevant as it will self destruct if it takes too much memory or takes too long to extract metadata this is a deliberate feature and not a bug!)

wrt not working - this could be because of bugs in the DB from 0.6.3 version. To repair simply call trackerd --reindex from terminal

No, haven't bothered reporting it, figured it was just alpha hiccups. I'll try --reindex and see if it behaves itself, though if there are really corrupt DBs from earlier versions, seems like the package update ought to trigger a reindex automatically.

Well, --reindex didn't seem to help anything. In my experience thus far on hardy, tracker is usually either indexing or displaying the '!' symbol, so I've just uninstalled.

On 20/02/2008, Thom Pischke <email address hidden> wrote:
> Well, --reindex didn't seem to help anything. In my experience thus far
> on hardy, tracker is usually either indexing or displaying the '!'
> symbol, so I've just uninstalled.

Same.

--
Martin

The problem for me is that it uses too much memory. Using a 1.5GB resident set (of 3.0GB total virtual) on a 2GB system means that everything else has to use swap, even if you're at +19 nice. And when IO is highly-contended already, even swap is slower than usual. It's actually so bad I'm losing keyboard events in X. The funny thing is that I can't just change the settings because it's another user's trackerd process running, even four hours after she has logged out. She only rarely uses this computer and her home directory contains just 250 jpgs and 4 docs and she doesn't use Evolution or Totem.

Having read similar bug reports going back to early 2007, I can see that a fix is nowhere in sight, leaving me little choice but to remove the whole package.

I also freed up about 1GB of disk space by doing this after uninstall:

sudo rm -rf /home/*/.cache/tracker /home/*/.local/share/tracker