Epic fail
I was wondering why KDE was so unusable the last days.....

http://s14.postimage.org/ocsmdgmkx/epic_fail.png

now I know....

PS: For non german speaker "fortsetzen" mean something like "put on"

I welcome any help to get the rid out of it..

I believe that you are referring to virtuoso-t process, but I can't be sure.
There are bunch of posts about debugging Nepomuk/Virtuoso high CPU usage (and the same number of bugs report, unfortunately). This is one of better places to start:
http://kdeatopensuse.wordpress.com/2011/11/09/debugging-nepomukvirtuosos-cpu-usage/
(most likely you can directly go to "isql-vt" command, as your virtuoso is probably listening on port 1111)
Also, this post may be useful if you want to provide some information in one of various bug reports:
http://dirac.org/linux/gdb/06-Debugging_A_Running_Process.php

When you know what query causes that CPU usage, please post it here - maybe someone will have an idea what can be done about it.

You may also go brute-force and try rebuilding Nepomuk database. Please note that as for 4.8.x option to import semantic information is apparently broken, so you will loose all your tags, ratings etc. in process.
If you are sure, follow these steps:
1. Logout of any KDE session you might have running.
2. Go to TTY console: press Ctrl+Alt+F1
3. Login as your user (put username and password, as usual).
4. Command to execute: cd "$(kde4-config --localprefix)"/share/apps/nepomuk/
5. Another command: mv repository repository-old
6. You are done. Logout of this session and log in to KDE (Ctrl+Alt+F7 should get you to KDM; or simply sudo reboot to reboot your computer).

These commands will change name of directory in which Nepomuk stores it's database. On next login, it will realize that there is no database and will recreate it (causing all files to be indexed, so you should be ready for some time with quite high CPU usage). When it finish it's job, everything should be back to normal.
Also, if you are using KRunner heavily (I do), you may disable it's Nepomuk plugin. When I do some computing (through '=' keyword) Nepomuk rushes with queries that take much CPU usage and dozen of seconds to complete (and returns nothing).

In some cases I have also found that it is sufficient to logout and back in again (ensuring that virtuoso-t exits in between). Sometimes a temporary condition occurs which causes this behaviour.

Gentlemen, I have a question.

These commands will change name of directory in which Nepomuk stores it's database. On next login, it will realize that there is no database and will recreate it (causing all files to be indexed, so you should be ready for some time with quite high CPU usage). When it finish it's job, everything should be back to normal.

If I do so, will all my emails be rescanned too?

Aleksey_R wrote:If I do so, will all my emails be rescanned too?

You will loose your index database, so I believe that answer is "yes".
But the real question is: is this bad (taking much resources)? It depends on your mail configuration.
IMAP accounts works the way that only message headers are downloaded, and message body is downloaded on request. I doubt Nepomuk will request all your messages only to index them, so it will at best index messages while you are reading them. No resource penalty here.
As for POP3 account, they already lies on your hard disk, so Nepomuk may index them. And huge mailboxes may take some time. But I wonder what is relation between Akonadi and Nepomuk. Akonadi stores messages in cache and provides unified access to resources. So if Nepomuk is capable of asking Akonadi for messages, then indexing should be relatively fast (it's faster to read something from database than read many small files shattered across hard disk). But if Nepomuk can't ask Akonadi and you have huge maildir, then indexing mail may take some time, yes.

Well more than the high CPU usage itself (which is very common for virtuoso-t) the fail is that it uses 87% CPU AND that nepomuk controller says it is NOT running.
This is very important because it means you CAN NOT STOP virtuoso-t anymore !!!!!!!!!

Semantik desktop is a very big project, they have done a lot of work , think about a lot of thing and so one blablabla,
Sadely they have forgotten to put a switch that shut it down in case it fails...

So you go to http://kdeatopensuse.wordpress.com/2011/11/09/debugging-nepomukvirtuosos-cpu-usage/

and you do

Code: Select all

max@netbook:~$ ps aux | grep virtuoso
max       1934 36.5  2.8  47664 28484 ?        RNl  19:39   4:52 /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_ZT1776.ini +wait
max       2457  0.0  0.0   5608   840 pts/3    S+   19:52   0:00 grep --color=auto virtuoso
max@netbook:~$ cat /tmp/virtuoso_ZT1776.ini |grep Port
ServerPort=1111
max@netbook:~$ isql-vt -H localhost -S 1111 -U dba -P dba

*** Error S2801: [Virtuoso Driver]CL033: Connect failed to localhost:1111 = localhost:1111.
at line 0 of Top-Level:

max@netbook:~$


that was the fail number 2

And finally you remains working with a computer that only has 50% of CPU free because of a programm that you CAN NOT stop...


Ideally if we would have more consideraion of end-user and would do more failure-analysis:
1) There would be within the Semantik desktop projekt a system that stop indexing no matter what happens and that is always ABLE to do so
2) There would be a reliable way to debug it (see fail 2 above)
3) There would be an easy way so that even the last is able to destroy all of its semantik database (not logging out of KDE and blablabla...)

In this case, it seems Virtuoso is running when it should not be (which is definitely a bug in it - however Virtuoso is not a KDE application). When you see a scenario such as this one, it is perfectly safe to kill Virtuoso, it should replay any uncompleted transactions.

You can kill -9 virtuoso-t as much as you want it will restart as much as it wants and continue to annoy you seemlessly

Currently in my case the only solution is to run kde without semantic desktop
all the efforts of all programmers jeopardized because of a lack of functional analysis ...

In the case where virtuoso-t appears to have gotten itself into a loop, I recommend removing the contents of ~/.kde4/share/apps/nepomuk/repository/ to allow Nepomuk/Virtuoso to get a fresh start (and thus hopefully fix whatever corruption is causing the loop).