Version: (using KDE 4.4.0) OS: Linux Installed from: Ubuntu Packages This problem has been around for a while, but I hoped it would stop with virtuoso. Yet is still there: as long as there is nepomuk related activity (strigi indexing, work in akonadi resources etc.), the processes virtuoso -t and nepomukstorage take almost 100% of my cpu. Strigi seems to rescan all my folders every time I log in. It doesn't seem to index everything, but still it takes a while to look at all the folders, and virtuoso and nepomukstorage burden my system (especially kontact, which I work with most of the time)
I have exactly the same problem. Very high CPU usage. I have let the process run but it doesn't go away. I gave 256Mb to vitruoso too. KDE has just suspended indexing to preserve resources as I write this!!! I have tried nicing everything but it doesn't seem to make it play much nicer. This was the case in 4.3 and now also in 4.4. KDE 4.4 (Kubuntu Karmic)
When exactly is the CPU usage high? When writing an email? During indexing? All the time?
When indexing. Although a day after I finished writing the comments above the indexing completed and now strigi is idle and I presume just indexing changes. But it was a painful experience getting there!! KDE shut down the process on more than one occasion "to preserve resources". This surprised me as in KDE3 days I had played with strigi and found it true to the description of light and blazingly fast. This makes me wonder if it is something to do with strigi passing the data to storage and hitting some blocking or timeout issues... I am also experiencing very long query times in Dolphin on simple queries. Perhaps there is much more breakage in my system than I am aware of. I upgraded Kubuntu to Karmic from Jaunty over the months. Very sorry I can't give you more here. This could well be Kubuntu's problem. If you have any diagnostics you would like me to run please let me know what you want! I REALLY WANT the KDE searching to work and work well!!!!!!!!!!! Thanks for all you are doing.
Just to be clear: Strigi is indeed fast and lightweight. It is the Nepomuk framework which does a lot of extra data handling. This is what slows down the indexing. I am constantly trying to improve that though. The suspension of Strigi is a bug which seems to be triggered by faulty signals by the KDE power saving system. I am investigating. The slow query issue is another one which should already improve a lot with KDE 4.4.1. This will improve further when we optimize the database settings over the course of the 4.4 series. Thanks for your patience.
Dear Sebastian, I suspected something like that. I can't be sure it is not a poor packaging issue via Kubuntu or something broken on the laptop. Recently Strigi started eating all the memory and I have currently had to remove it totally. I welcome pointers so I can give you good feedback all I have written I realise is vague and hence lacking in value for you! Regards, Kevin On Wednesday 03 March 2010, Sebastian Trueg wrote: > https://bugs.kde.org/show_bug.cgi?id=228081 > > > > > > --- Comment #4 from Sebastian Trueg <trueg k3b org> 2010-03-03 10:07:26 > --- Just to be clear: Strigi is indeed fast and lightweight. It is the > Nepomuk framework which does a lot of extra data handling. This is what > slows down the indexing. I am constantly trying to improve that though. > > The suspension of Strigi is a bug which seems to be triggered by faulty > signals by the KDE power saving system. I am investigating. > > The slow query issue is another one which should already improve a lot with > KDE 4.4.1. This will improve further when we optimize the database > settings over the course of the 4.4 series. > > Thanks for your patience. >
It is my impression that it is not so much CPU usage that affects me as a user. Rather, it's IO. Currently, nepomuk/strigi + virtuoso account for about 600 to 1300 K/s disk read, according to iotop. Virtuoso consistently takes up >> 70% of the share. Apps already running are still perfectly usable, but launching new apps is rather slow. I've tried to ionice virtuoso and according to the output of ionice itself this was successful. However, iotop still shows virtuoso tasks running with priority be/4, i.e. the default best effort priority.
I suffer from the same high CPU/IO issue for the virtuoso-t process when strigi is "doing something". Let me explain the "doing something": Without better knowledge of the details, I'd expect strigi to index each file exactly once, and then re-index it only if the file changes. Normally, you'd use a mechanism like inotify therefore. But as it stands (with KDE 4.4.0 and 4.4.1), it seems strigi runs every half an hour or so through all directories I index, and manually checks if something needs to be re-indexed. At least the "Search Service" taskbar icon always says "Strigi is currently indexing files in folder..." when the virtuoso-t process takes much CPU and IO load. My index contains about 30.000 files, most of which are source code files in deeply nested, rather big directories, if that makes a difference.
Hi, I am having all the problems reported here and, besides, it seems strigi starts indexing every time the AC adapter is plugged (maybe related to the problem Sebastian commented above in the KDE power saving?). To summarize the problems I am experimenting are: - strigi periodically looks in all the indexed directories trying to find if some files have changed. - virtuoso-t process shows high I/O usage and CPU load
I'm running Kubunutu Karmic on my Laptop and I've notice absurd CPU usage as well. I looked in the System Monitor process list and virtuoso-t was the culprit. I disabled all the search stuff and now my CPU usage is more reasonable. This is especially painful because my Laptop (Dell Latitude E6400) will reduce the frequency ceiling if it get too hot. So it would get to a point where it would only run at 800MHz. Of course it would still be at 100% on both cores so everything was painfully slow and it never cooled down. Before I figured out that it was virtuoso-t I thought it was Flash. One trick that seems to help is preemptively throttling the CPU to 2.13GHz with cpufreq-set. The normal ceiling is 2.66GHz. Fortunately in January Dell released an updated BIOS that fixed a particularly nasty bug in the throttling. What would happen is that once the CPU was throttled down it wouldn't be unthrottled. So even if I let the CPU cool down it would remain stuck at 800MHz until I rebooted. This is a major flaw and it should be fixed in a 4.4.x update. Please don't make us wait for 4.5
I am running KDE 4.4.5-1 and I am having trouble with kmail freezing and it appears to be because virtuoso-t is running, taking up 100% of the CPU. When I kill it, I can work again immediately in whatever I was doing (usually composer) prior to the freeze. The size of the log file - ./.kde/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.log was mentioned in one thread and that is only 1.3 M in my system. I am using Debian Unstable (not usual for me but I am hoping to get some bug fixes for Kontact ASAP) on a laptop with an AMD dual core processor. Fortunately use of the terminal is not affected so I can get to top and kill the process. However, users who are not aware of how to do this will be very frustrated with kmail. I am reporting this both for nepomuk and kmail. By the way, Konqueror keeps crashing when I am using the bug reporter so I had to cut and paste this report in before konqueror closes abruptly. I think it is happening when I click to move the cursor in the report I am writing but I am not sure yet. I will try to report that as well.
Just made a remark along the same lines: https://bugs.kde.org/show_bug.cgi?id=227589 Open Konsole, stop Akonadiserver (akonadictl stop), start Akonadiserver (akonadictl start), start kontact in konsole and watch the chatter of Akonadiserver. I get a freeze of kmail and a second later I get the akonadiserver chatter mentioned in the other bug. Once the chatter passed, it takes 3 seconds and kmail gets usable again, after 10 more seconds, performance is even ok, degrades again, freeze, chatter...
*** This bug has been confirmed by popular vote. ***
I'm not sure but maybe the bug that konqueror freezes temporarily after downloads (while virtuoso-t causes high cpu load) is related? After killing or interrupting virtuoso-t konqueror gets free again. This has not happend in KDE SC 4.4.x, it happens since 4.5.x: Bug 254373
Created attachment 54083 [details] iodbc log file when virtuoso-t process uses ~90% CPU I'm attaching compressed iodbc log file, created when virtuoso-t process is using %90 CPU. Since file is gone ~100M in a few minutes, I've stripped and compressed it. I'm using Soprano: 2.5.3, KDE 4.5.4, Qt 4.7.1, using Pardus binary Pisi packages.
duplicate of bug 246678?
*** This bug has been marked as a duplicate of bug 246678 ***
Created attachment 60797 [details] syslog This problem still exists in KDE 4.6.2 (running Kubuntu 11.04).