GNOME Bugzilla – Bug 689302
tracker-miner-fs makes system very slow after login
Last modified: 2017-10-03 00:41:58 UTC
For 9 minutes after I log in, tracker-miner-fs does its best to use all of the bandwidth that my system's poor hard disk has available. strace reveals that it is reading the 2.1 GB file ~/.cache/tracker/meta.db, and dstat reveals that it uses between 500 KiB/s and 20 MiB/s to do so. During this time, the system is, it's fair to say, somewhat unresponsive. Once I manage to get a terminal up, tracker-control reports: (tracker-control:3084): Tracker-CRITICAL **: Could not get miner progress for 'org.freedesktop.Tracker1.Miner.Files': Timeout was reached Could not get status from miner: org.freedesktop.Tracker1.Miner.Files (tracker-control:3084): Tracker-CRITICAL **: Could not get miner progress for 'org.freedesktop.Tracker1.Miner.Applications': Timeout was reached Could not get status from miner: org.freedesktop.Tracker1.Miner.Applications After it finishes doing whatever it's doing, the system returns to its normal responsiveness.
What version of Tracker specifically are you using?
Also, how much data / how many files have you configured for indexing? Are you indexing the whole home folder?
I'm running 0.14.1. As far as I remember, I haven't modified the configuration for what tracking will indexed myself. The GUI indicates the following directories: /home/sam (not recursive) /home/sam/Documents /home/sam/Downloads /home/sam/Music /home/sam/Pictures /home/sam/Videos The recursive folders only come to 211 MB. My whole $HOME folder is 93 GB. 76 GB of that is /home/sam/src. Even though I think this folder shouldn't be indexed, search results indicate that it is. I don't really mind this; I'm just concerned with the bad performance that I see when I log in.
Can you please paste your /home/sam/.config/user-dirs.dirs? Tracker before 0.14.3 used to index the whole home folder by default depending on the XDG user dir configuration.
XDG_DESKTOP_DIR="$HOME/" XDG_DOWNLOAD_DIR="$HOME/Downloads" XDG_TEMPLATES_DIR="$HOME/" XDG_PUBLICSHARE_DIR="$HOME/" XDG_DOCUMENTS_DIR="$HOME/Documents" XDG_MUSIC_DIR="$HOME/Music" XDG_PICTURES_DIR="$HOME/Pictures" XDG_VIDEOS_DIR="$HOME/Videos" NB, the desktop button is greyed out in tracker-preferences--the message about it being disabled since it's the same as another folder is there.
The desktop folder is indexed by default. Even though the tracker-preferences UI detects the overlap, tracker-miner-fs 0.14.1 doesn't. You can check the effective configuration with dconf read /org/freedesktop/tracker/miner/files/index-recursive-directories If '&DESKTOP' is in the returned list, tracker 0.14.1 will index the whole home folder recursively. If that's the case, I recommend you to upgrade to tracker 0.14.3 or later or explicitly remove the desktop folder from the configuration. As you wrote that you haven't modified the configuration, this bug should likely be resolved as duplicate of bug 680172.
I only see ['&DOCUMENTS', '&DOWNLOAD', '&MUSIC', '&PICTURES', '&VIDEOS'] in the list, but I agree this sounds very similar to bug 680172. I'll move my .cache/tracker out of the way and log in again and see what happens.
Same problem, tracker-xxxx processes with high IO transfers after first logon to Gnome-shell
Sounds like distros need to upgrade! Chusaco, are you able to test with 0.14.4 too? I suspect the issue isn't a problem with that version.
Hi Martyn, sorry to hijack this but I think it's still a problem with the latest versions of tracker; take a look at bug #645756.
In bug #645756 Martyn asked: > If you cleanly shutdown, it should be doing nothing on start up. > The store should just be updated with states of the volumes on your machine > (to disable files for removable devices) and then wait for work > from tracker-miner-fs. If it's writing to the database (which it > sounds like it is if you see it in iotop), something else is happening. Alright, here I am. I'm not sure how to investigate this though. While my laptop does not have such crazy symptoms as "9 minutes of grinding on login" as Sam Morris reported above, my ~/.cache/tracker/meta.db file is 360 MB instead of 2 GB. My XDG dirs are all standard/default stuff, except that: XDG_DESKTOP_DIR="$HOME/" Perhaps a key difference between my setup and Martyn's (as mentioned in that other bug report) is the fact that my laptop is not using a solid state drive. I'm pretty sure that makes the world of difference.
From my PoV it's fixed with a newer version of tracker; I'm running 0.16.2 and .cache/tracker is a much more sensible 15 MB. :)
(In reply to comment #12) > From my PoV it's fixed with a newer version of tracker; I'm running 0.16.2 and > .cache/tracker is a much more sensible 15 MB. :) Thanks for verifying Sam :) (In reply to comment #11) > In bug #645756 Martyn asked: > > > If you cleanly shutdown, it should be doing nothing on start up. > > The store should just be updated with states of the volumes on your machine > > (to disable files for removable devices) and then wait for work > > from tracker-miner-fs. If it's writing to the database (which it > > sounds like it is if you see it in iotop), something else is happening. > > Alright, here I am. I'm not sure how to investigate this though. I was writing a command line option for tracker-control last night to make investigations like this easier, I end up asking the same things all the time :) Anyway, if you're interested and running git master, you can use: tracker-control --collect-debug-info Details here: https://git.gnome.org/browse/tracker/commit/?id=e220a017a155e951a6ce7b61c44234d7d10dfe08 > While my laptop does not have such crazy symptoms as "9 minutes of grinding on > login" as Sam Morris reported above, my ~/.cache/tracker/meta.db file is 360 MB > instead of 2 GB. > > My XDG dirs are all standard/default stuff, except that: > XDG_DESKTOP_DIR="$HOME/" OK, if you can't run the tracker-control stuff on master as above, can you paste in here the following from your terminal: $ gsettings list-recursively|grep -i tracker and $ tracker-stats and $ tracker-control -F (this last one will follow the status of tracker, I am interested in knowing if anything is happening or if everything is idle, etc). That way I can get some idea of what settings you're using and the data indexed so far. > Perhaps a key difference between my setup and Martyn's (as mentioned in that > other bug report) is the fact that my laptop is not using a solid state drive. Solid state makes some difference, but I expect it to be a 0.14.x vs 0.16.x thing or a config and data set thing. Out of curiosity: 1. What Tracker version are you using, I think it's 0.14.x right? 2. When did you last reindex? Based on those things above, I should get a pretty good idea of what's going on and the state of things. My initial hunch is that a) you're using 0.14.x and b) you're recursively indexing $HOME because &DESKTOP points to $HOME (which is not good if you have a lot of source code and other stuff you don't want to have indexed). We avoid indexing $HOME these days because it was just causing too many problems. However, if the XDG dir configuration is a bit broken, well... :) We should really check for that and at least warn about it in the logs. Finally, if you want to get some idea of what Tracker is really going, you can do this: $ tracker-control -t (stop all processes nicely, -k if that doesn't work) $ /usr/libexec/tracker-miner-fs -v 2 (this will show you what is going on, -v 3 if you want even more debug information) I suspect this process never finishes working, you can check that with --no-daemon and it will exit when it completes the index. Hope this helps :)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!