I was trying to figure out why my computer is super slow to the point that I have to do a hard reboot to have it useable again and I found the "tracker-store" process to use 90-100% CPU (I think when it shouldn't be due to pausing or something) but more prominently I watch (with gnome-system-monitor) the memory increase from around 5MB to over 3GB! The uptime on the time before typing this was 16 minutes and I had to kill the process so that my computer can be useable. If more information is needed, just ask.
severity 612242 important thanks How big is your home directory? How big is your tracker index (~/.cache/tracker)? Does it help, if you tell tracker to nuke the existing db and restart fresh (tracker-control -r). You might create a copy of ~/.cache/tracker and ~/.local/ Michael
I have similar issues with tracker on a MacBook Pro (Core2 Duo CPU, 2GB RAM, amd64 arch). When the miner runs, it will use close to 100% of both CPU cores. More critically, there are memory leak problems. When I am not paying attention to the memory usage, the multitude of tracker processes keep growing until there is 100% memory usage and I have to halt the machine. I just killed a bunch of zombie processes that in total were using over 1GB of RAM. Home directory is ~100GB; the tracker index is ~500MB. I have not yet tried nuking the DB because I donât want to encourage it to start rebuilding, since it makes the computer so unresponsive. Iâll try it overnight.
Just wanted to update that I am seeing similar behaviour on an i386 system. I just killed 24 zombie tracker processes 40 minutes after booting the system; they were using a total of ~256MB of memory.
Hello, I experience similar problems, which started after upgrading to wheezy one or two weeks ago. The ~/.cache/tracker and ~/.local directories contained 1,2G and 50M respectively. I deleted them and within a few days they grew back to 1,1G and 37M. Judging from the ouptut of the 'top' command, tracker did not exhaust memory (2G, no swap) and CPU (dual 2.00GHz). But the IO stress it puts on the machine is enough to render it almost unusable, as for instance even the mouse pointer is sometimes completely frozen. Parallel daily cron jobs started at boot time, for instance running apt-get updates, probably aggravate the IO stress a lot. I am currently having tracker 0.14.0-2. Cheers,
Le Mon, Apr 16, 2012 at 09:31:09AM +0900, Charles Plessy a écrit : Hello again, on the same machine, I replaced my whole home directory by a fresh one. This solved the problem for a bit more than one month, but tracker came back blocking my computer this morning. Its version is now 0.14.1-1+b1. The only solution I found for the moment is to purge tracker with dpkg --force. Have a nice day,
I had similar problems, which started after I changed my system from i386 to amd64. I also had locale problems, because my .xsession specified locales which I had not generated. After reconfiguring my locales in a consistent way, the tracker problems disappeared. Best, Simon
Le Mon, Jun 18, 2012 at 08:16:22AM +0900, Charles Plessy a écrit : Just for the record, I re-installed Debian (Wheezy) on the same machine after replacing the mechanical hard drive with a solid-state disk, and I do not observe any problem at the moment. I can not tell if the key difference is the absence of configuration cruft, the performance improvement, or the smaller quantity of data on the drive. Have a nice week-end,
I experience this issue in the Jessie and reconfiguring locales does not fix the issue. I tried removing all locales but one, but no avail. Any ideas how I can work around the issue? Removing tracker's configuration directories in .local and .cache did not help.
I have problems like described here currenty with Testing on my Laptop. Every late evening the collection starts, making the computer unusable for around an hour (2 TB harddisk). Even the clock display then freezes until the process is finished. How can I disable that? DS
single file (as listed in /tmp/tracker-extract-files.1000/) The same file
was listed there for several days and tracker-miner was using 100% of a
single CPU thread.
I do not think this is related to the original bug though the symptom is
similar. I'm not sure if I should add to this bug report or start a new
one. The problem file is not proprietary and I can submit it for testing if
that would be helpful.
This is on Debian 9, new install and running 1.10.3 version of tracker:
hbarta@yggdrasil:~$ apt policy "tracker*"
tracker-extract:
Installed: 1.10.3-1
Candidate: 1.10.3-1
Version table:
*** 1.10.3-1 500
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
tracker-search-tool:
Installed: (none)
Candidate: (none)
Version table:
tracker-gui:
Installed: 1.10.3-1
Candidate: 1.10.3-1
Version table:
*** 1.10.3-1 500
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
tracker-miner-fs:
Installed: 1.10.3-1
Candidate: 1.10.3-1
Version table:
*** 1.10.3-1 500
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
tracker-utils:
Installed: (none)
Candidate: (none)
Version table:
tracker:
Installed: 1.10.3-1
Candidate: 1.10.3-1
Version table:
*** 1.10.3-1 500
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
hbarta@yggdrasil:~$
Thanks!
Was observing high CPU usage and memory leak after upgrading to Debian testing. And... lucky me, I found this bug report. Read through and decided to follow what others have done. I removed the directories ~/.cache/tracker and ~/.local/share/tracker. My computer was back to normal :)
Workaround: bartm@hostname:~$ cat /home/bartm/bin/cpulimit-autostart.sh #!/bin/bash set -e cpulimit -q -b -l 40 -e tracker-extract cpulimit -q -b -l 40 -e tracker-store cpulimit -q -b -l 40 -e tracker-miner-fs bartm@hostname:~$ cat /home/bartm/.config/autostart/cpulimit-autostart.desktop [Desktop Entry] Type=Application Name=automatic start of cpulimit NoDisplay=true Exec=/home/bartm/bin/cpulimit-autostart.sh