After about a day of computer uptime I notice that nepomukservicestub is consuming 210MB of my total 2GB of memory. That seems quite high. Is this normal? (If normal, I don't find it acceptable!) Actually it's consuming more than this since there are a bunch of instances of nepomukservicestub running, though most of them are consuming about 2-7MB of memory.

Assuming this is a problem and possibly specific to my system, how might I stop and restart nepomuk? (Just by killing it and then running the killed processes again?)

Which version of KDE SC are you using? Also, which backend are you using? Virtuoso is preferred for KDE 4.4 and later. Sesame2 for KDE 4.3 and earlier.

Go to System Settings -> Advanced -> Desktop Search -> Advanced Settings -> Memory Usage

I'm using KDE 4.3.4 with the Sesame2 backend. I don't see any setting for memory usage in the Desktop Search settings. There's just Strigi settings.

By the way, I can't get Strigi to index the contents of pdfs. Is this normal? Moreover the only way to access strigi's database for certain files is via the strigiclient and not via Dolphin's nepomuk search.

Only KDE SC 4.4.0 and later has the memory usage control setting available.
Dolphin also has improved interaction with Nepomuk in this release.

bcooksley wrote:Only KDE SC 4.4.0 and later has the memory usage control setting available.
Dolphin also has improved interaction with Nepomuk in this release.

That's good to hear. More to look forward to in the 4.4 release.

molecule-eye wrote:

bcooksley wrote:Only KDE SC 4.4.0 and later has the memory usage control setting available.
Dolphin also has improved interaction with Nepomuk in this release.

That's good to hear. More to look forward to in the 4.4 release.

Please note that you can limit Nepomuk memory usage but not virtuoso memory usage. In my system virtuoso is using 231162 K, the double of the most eating memory process in my system: plasma.

I haven't problem because all my computers has at least 4 GB but I wonder how KDE 4.4 works in a system with only 512 MBytes?

I will say that KDE 4.4, upon booting up the system using all the same software and kernel (only QT 4.6 is new), it is using anywhere from 25 MB to 40 MB more RAM than KDE 4.3. I posted this in another section of the forum and also filed a bug report. Please let me know if you have the same experience between the two versions. Much appreciated.

With my machine Nepomukservicestub will keep filling memory till it crashed, ultimatley running out of ram, last night it filled all 8 gig i have and my machine crashed, i have set it to 100 meg in settings but it still keeps climbing, if i disable strigi it runs as normal? Is it a bug ?

The memory usage limitation only applies to the storage database it uses and not Strigi or the various Nepomuk feeders which may have memory leaks.

If you can reproduce this and capture the full command of the faulting process this would be helpful.

Hmm, it seems to me there is something wrong... (mem usage in kB)

Code: Select all

$ ps -C nepomukservicestub v
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 3519 ?        Sl    12:19     29    21 485810 21508  0.3 /usr/bin/nepomukservicestub nepomukstorage
 3618 ?        S      3:00    123    21 290246 27632  0.4 /usr/bin/nepomukservicestub digikamnepomukservice
 3621 ?        S      3:04      1    21 189062 20456  0.3 /usr/bin/nepomukservicestub nepomukqueryservice
 3622 ?        S      3:20      1    21 187018 21168  0.3 /usr/bin/nepomukservicestub nepomukremovablestorageservice
 3624 ?        Rl     3:11      9    21 281178 25040  0.4 /usr/bin/nepomukservicestub nepomukontologyloader
 3626 ?        Rl     3:11      1    21 3567742 3137876 51.2 /usr/bin/nepomukservicestub nepomukfilewatch
 7764 ?        SNl    1:15     71    21 499982 53328  0.8 /usr/bin/nepomukservicestub nepomukstrigiservice

This is a known issue with the Nepomuk File Watcher. It is a memory leak which the Nepomuk developers have been unable to trace.

bcooksley wrote:This is a known issue with the Nepomuk File Watcher. It is a memory leak which the Nepomuk developers have been unable to trace.

If is a know problem without solution I don't see why developers don't implements an automatic restart of this process when it eats so much memory. I think that a pause time to time, for example before strigi starts indexing, is better than a crash.

Luckily memory leaks are located in a subprocess so this solution must be easy to code.

At this time I believe they are trying to locate the cause of the leak.

To resolve it temporarily, you can kill it, and it will be automatically respawned.

Thanks, I'll try it until it will be fixed.