Just installed Debian Squeeze, thinking it was basically stable, it is giving a lot of trouble. Trouble includes virtuoso-t using up to 100% of CPU; this on a fairly large computer that rarely uses more than about 3%. Dual core AMD processor, 4GB RAM.

This excessive usage can be stopped by "kill"ing nepomukservices or similar spelling a few instances. But this has to be done manually after every re-boot. Any way of stopping this from happening automatically?

Incidentally KDE is dodgy generally - e.g. compositing and transparency tends to get switched off. Any way of calming the whole thing down?

Which graphics driver does your system use? Also, which version of KDE do you use?

You may wish to try disabling the Contacts and Nepomuk Search runners in KRunner.

bcooksley wrote:Which graphics driver does your system use? Also, which version of KDE do you use?

You may wish to try disabling the Contacts and Nepomuk Search runners in KRunner.

Nvidia's proprietary driver, NVIDIA-Linux-x86_64-260.19.29.run if that's any help. Sorry to be thick but can't work out kde version, other than kde4.

You can find the version from a KDE application (Help -> About KDE) or by running

Code: Select all

kde4-config --version

Do you have Strigi and Nepomuk enabled? (Desktop Search in System Settings.)

Hans wrote:You can find the version from a KDE application (Help -> About KDE) or by running

Code: Select all

kde4-config --version

Do you have Strigi and Nepomuk enabled? (Desktop Search in System Settings.)

Code: Select all

kde4-config --version
Qt: 4.6.3
KDE Development Platform: 4.4.5 (KDE 4.4.5)
kde4-config: 1.0

Yes both enabled. But after about 3 days you'd think they'd have created the database and would no longer need vast amounts of CPU?

Given that you are using KDE 4.4, I would recommend disabling Strigi indexing.

Huge thanks. I'm using the version of KDE that comes with Debian Squeeze. Perhaps I should update to a better, more recent version? By analogy 'mplayer' is best compiled from svn source; the version that comes with Debian is full of problems.

Hope not veering of topic but how install most modern KDE?

The latest KDE release is 4.6, there may be Debian packages available for this, however you may wish to try building it from source.

I believe generic instructions for building KDE from source are available on techbase.kde.org.

bcooksley wrote:The latest KDE release is 4.6, there may be Debian packages available for this, however you may wish to try building it from source.

I believe generic instructions for building KDE from source are available on techbase.kde.org.

Great thanks, try that.

Hi,

I'm using kde 4.6.4 with kdepim 4.6.0, disabled contacts and nepomuk runners in krunner and even strigi disabled in the system settings. The virtuoso-t process is still found at the top of top . Interestingly the three procecsses taking most of the aggregated CPU time of the computer are after the upgrade virtuoso-t, dbus-daemon(!) and nepomukservicestub. Disabling nepomuk brings everything back to normal (not taking the different akonadi-flaws into account ).

Any more hints or ideas?

Thank you!

It is possible that Akonadi is indexing your emails. This would create a high load within Nepomuk, and explain the high usage by virtuoso-t and dbus-daemon (as Nepomuk and Akonadi communicate via D-Bus)

bcooksley wrote:It is possible that Akonadi is indexing your emails. This would create a high load within Nepomuk, and explain the high usage by virtuoso-t and dbus-daemon (as Nepomuk and Akonadi communicate via D-Bus)

I thought so too - at first. But after letting the computer for 2 or 3 DAYS (24h) running over the weekend and it did not finish that, I concluded it is not something which should be like that . Including all accounts and folders, I have around 35k mails managed by akonadi. While this will surely take some time, but several days without any other load?

At the moment I am using the gentoo packages. Perhaps I should try some opensuse-repository or so

Mh, is there a way to get some dumps to see exactly what nepomuk/virtuoso/strigi/akonadi and whoever is connected to all this are doing?

Unfortunately i'm not aware of any way. You might want to check to ensure that Strigi had not started indexing your system though.

It could also be possible that virtuoso-t got itself into a lockup (which has been known to happen unfortunately)

Hello,

Thanks everybody for the info on this thread, since I was struggling with my laptop since I upgraded to KDE 4.8.0.

Virtuoso-t was just sucking my laptop's battery and CPU really badly the last few days. The DB of virtuosobackend got to 1,2 Gb due to the fact that I have +100,000 mails in my KMail (all my mails from back to the beginning of the Internet). Soon the index file will be bigger than the size of my mailbox.

When I upgraded KDE to 4.7.4 a few weeks ago and moved to KMail2 the Nepomuk pushed itself to my mailbox and the indexing became a major headache.

Mind you, this is a brand new ACER with Optimus Nvidia card, 8Gb RAM and i5 SandyBridge thechnology. It is really quick, I tell you. When I first install Slackware64 13.37 on it with KDE4.5.5 it was working rather well. It was running nearly 4 hrs on the battery (without NVidia enabled), but a number of minor issues with synaptics and system freezes forced me to upgrade the software to current and to new KDE versions. Once I moved to KDE 4.7.4 and KMail2 the indexing of my mails took a few days to complete. Battery started to last only 2 hrs and CPU load was always heavy, even if I used nothing. KMail2 in KDE4.7.4 had lots of bugs, akonadi and nepomuk related and I lost losts of mails before I managed to get on top of the situation. That's why I moved to KDE4.8.0 the day it was released. KMail started to work much more stable, but the Nepomuk mail indexing started anew and it took full 10 straight hrs to build a new index of 1.2Gb and this is really quick hardware.

So, I finally ended up here in search of the way to get on top of the virtuoso-t eating up my CPU and battery.

Now, after disabling Nepomuk in KRunner, switching off the Nepomuk Desktop Search and file indexing, the vent on the processor is finally down to low rotations and CPU graph is flat.

So, thanks again for this thread!

To be fair, I see the benefits of Nepomuk. File search through my +100,000 files was much quicker than the search which was each time running through all of my files. Mail search, which I tried before I disabled the Semantic Destkop was also VERY quick to find matches in +100,000 mails. But overload was TOO much even for such a quick machine.

I hope the SOPRANO developers (from Semantic Destkop) and KDE developers try to test their solutions on systems with thousands of mails and files.

For now, if I want to search my mails, I need to manually enable the Nepomuk and then do the search, and once I am done, I switch off the Nepomuk again.

Cheers,

Oliwer