Comment 17 for bug 131983

Revision history for this message
Jamie McCracken (jamiemcc-blueyonder) wrote :

There is still more work going on to improve things (notably index merging which means creating a smaller index when the main index is large and merging them together later on which should reduce iowait time during non-merge periods substantially as a small index can be updated much quicker)

1) is a known bug and will be fixed shortly. A workaround you can use in the meantime is to put a dummy path in the watch directories setting (uncheck index my home directory as well) and disable email indexing in preferences.

see https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/132320

Also we will be adding a pause indexing option to a tracker applet to make it easy to pause when the user desires

2) This is already fixed in svn. RSS stays at around 12-14MB during initial indexing with svn version (with heap around 6-8MB and about 5-6MB shared).

3) I would need more info on this. When does it happen? During watching? (we crawl all the sub dirs in your home dir before indexing to place watches on them). Does this only happen when watching/indexing is disabled in the prefs?

The more info you can give us here will help us solve this problem.

4) The point you raised is how sqlite works. Sqlite has its own journal (on top of the ext3 journal) so whenever a transaction is committed it writes to /tmp journal first. We cant prevent that - its part of sqlites' ACID compliance and general resistance to db corruption. As the index is expendable to us, it is not needed by tracker but the best I can do is request an option from sqlite team to disable journalling in the future. Sqlite recommends stacking up many writes into a single transaction for performance reasons which we do in most instances. We will check for any instances where this is not the case

Note earlier versions used qdbm not sqlite which did not do this. QDBM suffers more from fragmentation causing the index on disk to bloat up and prevent effective caching by the kernel when it gets too large (this would kill disk IO in itself)

5) already fixed in svn

6) http://www.sqlite.org/lockingv3.html

read section Rollback Journal. Sqlite defaults to creating a journal in /tmp but we can specify another path if there is a compelling reason?

anyway thanks for the feedback - the more constructive criticism you can give us the better we can make tracker for you