Bug 292517 - virtuoso-t eats constant bezween 90 and 151%
Summary: virtuoso-t eats constant bezween 90 and 151%
Status: RESOLVED DUPLICATE of bug 289932
Alias: None
Product: nepomuk
Classification: Miscellaneous
Component: storage (show other bugs)
Version: 4.8
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
Depends on:
Reported: 2012-01-26 21:14 UTC by Sascha Manns
Modified: 2012-02-08 14:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Manns 2012-01-26 21:14:27 UTC
Version:           4.8 (using Devel) 
OS:                Linux

After booting KDE 4.8.0 the virtuoso-t service starts. Then the process is finished. The Nepomuk Trayicon says it is inactive. But virtuoso-t works again and again with max 151% Systemressources.

Reproducible: Always

Steps to Reproduce:
Just start the system.

Actual Results:  
Many resources blocked and makes the system slower.

Expected Results:  
A virtuoso-t service with max 10% Resources
Comment 1 Gunter Ohrner 2012-01-28 18:09:32 UTC
Maybe I'm experiencing the same issue?

Running KDE 4.8.0 on Kubunto 11.10, virtuoso-t started on login and is running at 100% CPU (niced) since then. It even ran over night without finishing.

Meanwhile I disabled file and email indexing in the settings dialog hoping that this would help, but it did not change a bit. I even killall-ed virtuoso-t, but it came back after a while, still happily running at 100% CPU (still niced).

This causes noticable sluggishness of the system and an annoyingly fast (and thus loud) spinning fan...

If this is a separate issue, please say so and I will open a new report. (Or redirect me to an appropriate one if there already is any, I only found this one as a potential duplicate.)
Comment 2 Gunter Ohrner 2012-01-28 18:11:45 UTC
Ah, apparently bug 289932 describes my issue.

Sorry for the noise.
Comment 3 Vishesh Handa 2012-02-08 14:12:03 UTC

*** This bug has been marked as a duplicate of bug 289932 ***