I am using KDE 4.4.5 on Debian Squeeze x86_64. I have noticed a few times now that I have came back from being away from my laptop to notice the hard disk activity through the roof and the screen unresponsive. After moving the mouse, the lock screen sometimes takes up to 30 seconds to appear. Upon logging in I promptly stop Strigi from indexing and my machine was fine again. My machine is less than 6 months old, it is a Dell Latitude E6410 with an Intel Core i5 and 8gb RAM. I would like to use Strigi if possible, but there's no way I can possibly justify it if it's going to do such annoying things. I haven't changed any of the settings associated with Strigi - just the default 50mb RAM allocation.

Is there anything I can do to fix this, or some sort of alternative file indexer?

Which backend are you using?

TheBlackCat wrote:Which backend are you using?

I'm not sure. Whichever Debian uses by default. How can I check?

To check which backend is in use:

Code: Select all

qdbus org.kde.NepomukStorage /nepomukstorage usedSopranoBackend

You should see "virtuosobackend".

If you get anything else, especially "redlandbackend", then you need to check your KDE installation, look for a package named "soprano-backend-virtuoso" or similar.

How much data are you indexing? My system didn't encounter any high load when indexing... ( i5, 4gb RAM )
Your database could possibly be corrupt or damaged somehow though...

I get virtuosobackend.

It only seems to be bad whenever I go away and come back. It tells me there is 700mb in the database. I have a few terabytes worth of directories set up for it to index, but even after I changed it to include my external hard disks it was slow (and I only have about 200gb worth of stuff in my /home).

Can you please check which process in particular is using the CPU/Disk? htop and iotop should be able to help here.

bcooksley wrote:Can you please check which process in particular is using the CPU/Disk? htop and iotop should be able to help here.

I'll see if I can replicate the problem and then get back to you.

I sometimes have a similar experience - for example right now, after resuming my netbook from suspend. The process using 165% CPU was virtuoso-t.