Archive for November 2011
There was a lot of bug fixing regarding nepomuk and its indexing. However you might still get a high CPU-usage. Reporting this is a bit useless unless you can at least give some info about what’s happening.
So what you can do is query virtuoso’s status. On openSUSE it works like this: first find the .ini file currently in usage to get the port virtuoso is using, connect to virtuoso and finally query virtuoso for its status and running statements. The latter are unfortunately truncated so I would appreciate some hint on how to get around that.
ps aux | grep virtuoso
finds /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_T18122.ini +wait
cat /tmp/virtuoso_T18122.ini | grep Port
isql-vt -H localhost -S 1111 -U dba -P dba
which connects to virtuoso
which shows you some info and which queries are keeping the process busy. isql-vt is part of the virtuoso-server package but it might be that only recent packages have it compiled and older packages lack the tools.
will start logging every command send to virtuoso from the nepomuk service into the virtuoso.log file which should be next to your virtuoso.db, e.g. ~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/. Use trace_off(); to stop logging. See the virtuoso manual for more options.
Further you can do the following:
- open kdebugdialog and search for nepomuk
- use the quick-search to enable debug output for nepomuk
- on a konsole do: qdbus org.kde.NepomukServer /nepomukserver quit
- wait until nepomuk and virtuoso are gone
- restart it from the konsole: nepomukserver
UPDATE: There is yet another possibility to debug virtuoso-t, i.e. find out the currently active query. On a konsole issue the following commands:
- qdbus org.kde.nepomuk.services.nepomukqueryservice
- You will see something like /nepomukqueryservice/query64 if the query does not finish within a reasonable amount of time you can get the query string
- qdbus org.kde.nepomuk.services.nepomukqueryservice /nepomukqueryservice/query64 queryString should then give you the query.
UPDATE 2: If virtuoso-t consumes CPU although there are no active queries, the analysis has to go a bit deeper. Virtuoso is started through Soprano with certain parameters which are set in a temporary ini-file (/tmp/virtuoso_XXXX.ini). Soprano needs to be modified manually to start Virtuoso with different parameters in the ini-file, e.g. to improve virtuoso-t’s behaviour by modifying backends/virtuoso/virtuosocontroller.cpp (Soprano) and setting NumberOfBuffers to 40000 (line 344) and SchedulerInterval to 0 (line 350).
After re-compiling soprano one has to attach gdb to virtuoso-t as soon as it starts consuming CPU and create a full threaded backtrace:
set logging file /tmp/virtuoso-t.out set logging on thread apply all bt full
Note: The above changes should not be used as default values for packaging!
If you have any other hints regarding this piece of software feel free to mention them and I will add them to the post.