A little after I turned strigi on in the Nepomuk configuration (in system settings), I noticed my CPU load was consistently %100, and the load average would stay above 1.8.

When I checked the process table, "nepomukservicestub nepomukstorage" was the cause.

That process is often above %50 CPU, and 400 MB. Right now, it's %75 and 453MB. These values are from the KDE System Monitor.

Can somebody tell me why it uses so much of my system resources, and what it does?

I checked techbase, and userbase, but couldn't find a clear answer there.

I turned on strigi support a week ago, and before that my CPU was mostly idle, and total RAM used was usually less than 400.

I'm using KDE 4.1.2 via gentoo on a Celeron D 2.4GHz with 1 GiB RAM.

Thanks

That is it probably updating itself, although sometimes CPU usage would jump insanely for me also, for no reason whatsoever ( so I turned it off ). What soprano backend are you using? ( to find out, open konsole type in sopranocmd and look for this "--backend" below it will be a list of backends, you should have sesame2 installed ( redland eats CPU like no tomorrow for little work )

OK, Nepomuk (together with Strigi) aims to provide a Desktop search and much more. When you enable Strigi in the KDE settings it will create an index of all your files and store it in Nepomuk (thats why nepomuk storage is using cpu) .

The bad thing is: In KDE 4.1 there is no way (for endusers) to query the data (search for files with it). So at the moment there is no real use in enabling strigi in the KDE settings.

The huge CPU usage: The indexing (especially the first time) takes quite sometime and CPU. Depending on how much folders you have selected for indexing and the amount of files it can take several hours (first time). But, it should not make your computer a lot slower while doing so. It should only use CPU when no one else needs them. So your computer should feel nearly as fast as normal while doing that.

Memory usage: That is an real issue. Here we need some improvment. On my computer it is about 300 MB for Nepomuk (but only about 50 MB from the start).

Backend: bcooksley already said it. There are two avaible storage backends for Soprano (Nepomuk uses Soprano to store the data on the disk) redland and sesame2. Redland is very slow compared to sesame2. But well, sesame2 is java based, thats why some distros do not package it. You can find out which one with sopranocmd.

Thanks for the help. I haven't checked the forum in a while since I was expecting it to email me.

Anyway, I decided to just turn off nepomuk altogether, since, as was said, nothing could actually use it effectively. Besides, with the way I organize and use my computer, I don't get huge gains from a semantic desktop. I'm going to wait until I use akonadi and all that as well.

Since turning it off, my computer's been more responsive, faster, and no longer needs to be restarted from time to time.

The CPU usage wasn't actually strigi. All of nepomuk's processes are separate, and strigi barely used anything most of the time. That doesn't rule out some strigi-related effect, of course. It just wasn't the 'strigi' process.

My backend was sesame2, which surprised me, because I was sure I set it up for redland months ago, before I did the full switch.

I hope things improve by the time I try it out again. I'd offer help, but I really don't know how to, and I definitely don't have the time.

Your backend was more than likely set to sesame2 because redland is a CPU hog, and when it is the only Soprano backend available, will automatically disable Strigi indexing, unless the user specifically enables it after redland is the only available backend.

Regarding it not being Strigi, it isn't Nepomuk either. It is actually the glue between them ( Soprano ) which runs inside Nepomuk adding the Strigi indexed data into Nepomuk.