Comment 32 for bug 132741
Revision history for this message
| Jamie Lokier (jamie-shareable) wrote Re: [Bug 132741] Re: Tracker should not be enabled by default until it doesn't clobber everything | #32 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Jamie McCracken wrote:
> trackerd is niced +19 so cpu will nose dive to 1% if another app uses
> cpu. Indexing needs lots of cpu which no indexer can escape from.
> Switching to another will not change this
> (unless you consider slowing indexing to such a crawl that it takes
> days to index which you can do already in tracker-prefs by setting
> the throttle slider)
Does this work now? It had no noticable effect when I tried it, and
certainly didn't stop the I/O overloading problems. At all.
> Only slow downs Im aware of is during index merging and these are 100%
> due to I/O issues
Don't forget scanning files after reboot, just to check they haven't
changed. That takes a few minutes of heavy disk seeking, and is very
annoying after booting a laptop to do something quickly.
> during index merging I/O can become overloaded which can starve other
> processes of disk due to bugs in kernel (lots of small writes kills
> performance on ext3 but hoepfully ext4 will have pre allocation to
> alleviate this)
You shouldn't be doing lots of small writes with fsyncs - that's
application silliness.
I've explained how to avoid them at the db level but as far as I could
tell you weren't interested. To be fair, index merging is a smart (if
suboptimal) alternative - but you _really_ shouldn't have small writes
with fsync when merging indexes. That's algorithms from the 70s, long
ago solved. (See Knuth).
Imho, ext4 preallocation and delayed allocation will not make small
single-file writes with fsyncing much faster, if at all. But I would
like to be pleasantly surprised.
> In any event, next version of tracker (due this week) now pauses
> automatically during merges whenever the user moves the mouse or
> presses a key/button so there should not be any perceptible slow downs.
Oh boy. Talk about krufty hacks! 'Tis a good idea. What about
watching long TV/animations in Totem and other video players. Is that
affected? It would be a good idea to index during that, provided I/O
+ CPU isn't affected.
-- Jamie