WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Am Friday 30 December 2011 schrieb Martin Steigerwald:
> Am Freitag, 30. Dezember 2011 schrieb Rainer Dorsch:
> > Hello,
> > virtuoso-t (kde 4.7.4 from Debian experimental, which otherwise is
> > excellent !) consumes here a lot of CPU time (116% of a dual core)
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 28282 rd 39 19 843m 828m 6840 S 150 20.5 86:21.94 virtuoso-t
> > The problem does not occur at startup of KDE, but after a while (even
> > when I am away from the system I see the problem).
> > What information is needed to help narrow down the problem?
> I had this at times during initial Nepomuk desktop search indexing as
> well. But not all of the times. There have been times where virtuoso-t
> consumed lots of CPUs and then it has been quiet for a while.
> I did not see it since then.
> I had the feeling - completely unproven - that it got better after I
> raised the maximum amount of memory the database process may use under
> systemsettings, then "Desktopsuche | Erweiterte Einstellungen" ("desktop
> search | "extended settings" or something like that). I now have set it to
> 512 MiB, I think it was 64 MiB initially. I thought 512 MiB wouldn´t be
> too much considering that the laptop has 8 GiB.
I increased already before posting from 512 MiB to 1024 MiB. I did not see a
> Otherwise you can try disabling desktop search or wait till the initial
> scan is over.
For me it looks like on my stystem, after restarting the system nepomuk starts
indexing again from scratch, even when it seems to have completed the
> Nepomuk strigi/streamanalyser desktop indexing from KDE SC 4.7.4 seems to
> be the first one that actually made it through my home directory.
> Everything prior to that crashed at some file - without telling me which
> one. And it had way less resource consumption. But then it also took way
> longer for the initial scan to complete.