Bug 257435

Summary:	Nepomuk should wait more before indexing after startup
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Lukas <1lukas1>
Component:	Nepomuk Feeder Agents	Assignee:	Sebastian Trueg <sebastian>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	kdepim-bugs, trueg, vkrause
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Lukas 2010-11-20 19:48:47 UTC

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.

Comment 1 Rigo Wenning 2011-09-28 06:56:23 UTC

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.

Comment 2 Sebastian Trueg 2011-09-28 07:20:41 UTC

Re-assigning this bug to Akonadi since Nepomuk file indexing is not the problem.

Comment 3 Christophe Marin 2012-02-03 20:42:25 UTC

(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.

Comment 4 Volker Krause 2012-03-11 17:53:37 UTC

The Akonadi Nepomuk feeder has a much improved indexing throttling in KDE PIM 4.9 to address this.