Version: unspecified (using KDE 4.5.2) OS: Linux Currently Nepomuk, virtuoso and akonadi services starts running immediately after startup and heavily accesses hard drive for a few minutes. The problem, is that after boot/login it is reasonable to immediately run some application like firefox. Since both firefox and services uses HDD at the same time, access time gets enormous as the head has to jump across. I've seen increase of FF cold startup time from 15s to even 2mins compared. Reproducible: Didn't try Expected Results: These services could be ran with reasonable delay (e.g. 10-15mins) thus preventing collisions, when many HDD read operations is executed at the same time.
I just tried to start kontact after adding a 8k emails mailbox in the session before. Nepomuk + Virtuoso were hammering the system so heavily that kontact crashed with "couldn't set lock file" timeout. This has been a constant complaint about nepomuk & virtuoso since 3 years and nothing is done about it. A solution could be so easy: Give the user more control on when indexing starts. In this case I would let my machine run the indexing over night. The current configuration is just bad since 3 years and the current developers are too stubborn to change it. Just an easy on/off for indexing in the tray. Part of the issue here is also how to shoot up and wind down those processes quickly.
Re-assigning this bug to Akonadi since Nepomuk file indexing is not the problem.
(In reply to comment #2) > Re-assigning this bug to Akonadi since Nepomuk file indexing is not the > problem. I don't see how this could be an Akonadi issue. If Nepomuk is not available, the feeder doesn't do anything (except waiting for the nepomuk startup). And that's not all: by default the Nepomuk feeder stops immediately when it detects some user activity. What is reported here looks like what I experienced with nepomuk before wiping the whole db: 5 minutes before it becomes available and GB of data read.
The Akonadi Nepomuk feeder has a much improved indexing throttling in KDE PIM 4.9 to address this.