Could you please make sure you're running virtuoso 6.1.4 and NOT 6.1.5.

6.1.5 has a nasty bug.

thx for the hint, but it's 6.1.4-3127 ...

I have KDE 4.9 from kubuntu backports PPA and nepomukservicestub is consuming all available memory 1.5GB out of 2.0GB, makes the system totally unusable. Killing the servicestub just starts a new instance and the same procedure begins again, starting with some 50MB and then steadyly ever increasing until 1.5GB again.
Does not take 24hrs but rather 10 minutes.
Disabling Nepomuk Semantic Desktop in KDE settings "solves" the issue with the result of not being able to use CATEGORIES for contacts or calendar events any more.
I did delete all nepomuk system settings and the databases etc. Same procedure. No difference.
This is the most broken Nepomuk version ever.

4:4.9.0a-0ubuntu1~precise1~ppa1 32bit

I'm here at KDE-4.10 on openSuse 12.2 64bit and since a rather short time (probably since yesterday or so where I did a search in kmail) virtuoso uses 1.2GB !!
Even if I shut down nepomuk and akonadi completely and restart nepomuk (via systemsettings), virtuoso-t again uses 1.2GB RAM.
What information shall I provide or what can I check to find out why it uses that much RAM ?

(In reply to comment #4)
> I'm here at KDE-4.10 on openSuse 12.2 64bit and since a rather short time
> (probably since yesterday or so where I did a search in kmail) virtuoso uses
> 1.2GB !!
> Even if I shut down nepomuk and akonadi completely and restart nepomuk (via
> systemsettings), virtuoso-t again uses 1.2GB RAM.

Are you sure virtuoso still consumes 1.2 Gb ram even after restarting Nepomuk? Does it consume that much the moment it starts? How long does it take to go up to the 1.2gb?

Maybe Nepomuk didn't get started? You should try doing it manually via -

$ qdbus org.kde.NepomukServer /nepomukserver quit
-- Wait for it to end - check via `ps aux | grep nepomuk`
$ nepomukserver

It did consume 1.2GB after I activated nepomuk again in systemsettings. It did not take 1.2GB immediately after start but after I guess 2 minutes or so.

However I think it has to do with the last made search in kmail.
To verify, I did a new search inside my empty junk folder, and voila, virtuoso-t now only needs 70MB (I think I still needed to restart nepomuk to reduce the memory consumption).

If you can not verify this behaviour I'll need some more time to try to reproduce it

(In reply to comment #6)
> It did consume 1.2GB after I activated nepomuk again in systemsettings. It
> did not take 1.2GB immediately after start but after I guess 2 minutes or so.
> 
> However I think it has to do with the last made search in kmail.
> To verify, I did a new search inside my empty junk folder, and voila,
> virtuoso-t now only needs 70MB (I think I still needed to restart nepomuk to
> reduce the memory consumption).
> 
> If you can not verify this behaviour I'll need some more time to try to
> reproduce it

Take your time :)

We unfortunately cannot, but it would be great if you could check the queries running by doing this - http://vhanda.in/blog/2012/02/virtuoso-going-crazy-/

I have noticed this bug after updating to 4.10. But I have noticed something else: the extensions excluded from indexing, are indexed anyway. I saw this in Nepomuk configurations, when is shows the current indexing.

I haven't this already filled, could it be related to this bug?

I am experiencing this bug on Kubuntu 13.04 amd64 running KDE 4.10.2, virtuoso 6.1.6. Its a slow leak, but over the course of a day the virtuoso-t process grows from hundreds of megs to multiple gigs of memory (after 2 hours of running it is using 1.6G of memory). I have a large downloaded IMAP e-mail account, multiple google calendar's and a facebook sync, multiple google contacts and a ldap contact sync, plus a bunch of RSS feeds.

(In reply to comment #9)
> I am experiencing this bug on Kubuntu 13.04 amd64 running KDE 4.10.2,
> virtuoso 6.1.6. Its a slow leak, but over the course of a day the virtuoso-t
> process grows from hundreds of megs to multiple gigs of memory (after 2
> hours of running it is using 1.6G of memory). I have a large downloaded IMAP
> e-mail account, multiple google calendar's and a facebook sync, multiple
> google contacts and a ldap contact sync, plus a bunch of RSS feeds.

Urgh. Temporary solution - if virtuoso consumes too much memory just kill it. It will automatically respawn and continue.

I think I might just implement some kind of process to monitor virtuoso and kill it if it starts consuming too much memory.

I did that and it doesn't seem to start growing again. It did appear to stop growing at 1.66G. Is there any information I can gather the next time this occurs to help debug the problem? Any tools I can run on the process?

@Craig Please, watch out for potential Akonadi database corruptions. There were changes in the Akonadi DB format. I was suffering from this bug, until I ran this, in succession, in my KDE active session.

$ akonadictl fsck
$ akonadictl vacuum
$ nepomukcleaner

After that, and restarting my session, the memory leaks were gone, even after enabling the Akonadi Nepomuk Feeder per bug 315985 .

@Craig Also, please turn off the Facebook resource. It will continuously fetch updates from your timeline in realtime, and every update is a call to Akonadi Nepomuk Feeder. Also, since the Facebook resource is experimental, we can think it could be a source of the bugs.

(In reply to comment #12)
> @Craig Please, watch out for potential Akonadi database corruptions. There
> were changes in the Akonadi DB format. I was suffering from this bug, until
> I ran this, in succession, in my KDE active session.
> 
> $ akonadictl fsck
> $ akonadictl vacuum
> $ nepomukcleaner
> 
> After that, and restarting my session, the memory leaks were gone, even
> after enabling the Akonadi Nepomuk Feeder per bug 315985 .

Thanks a lot, Alejandro, for the tip, 

regards.

I removed the facebook resource, ran the akonadi commands and I am still experiencing large memory growth for virtuoso-t. It happens after almost every boot. The process tends to grow to over 1.5G relatively fast and then the growth slows down, but it does continue to grow. If I kill the process, it comes back and doesn't repeat the memory growth. I have akonadi resources for imap, ldap, a couple Google accounts setup, and owncloud.

Hmmm... Please, upgrade again. Sorry for being like a broken record, but KDE 4.10.3 has a rewritten Akonadi-Nepomuk feeder, and that can make the difference here. Check you have Akonadi 1.9.2. After that, run the command set and let the Nepomuk Cleaner work until it successfully ends. 

After you upgrade, and run those commands, restart your computer.

I'm willing to profile it if anyone can give-me a test case, or a way to reproduce.
Here it takes about 130MB.

I've currently again the situation that virtuoso-t is using approximately 724.6 MB of memory.
Here's what I find by doing what's written at http://vhanda.in/blog/2012/02/virtuoso-going-crazy-/

There are 2 queries:
/nepomukqueryservice/query139
/nepomukqueryservice/query95

qdbus org.kde.nepomuk.services.nepomukqueryservice /nepomukqueryservice/query139 queryString
select distinct ?r ?reqProp1 where { { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/18b6518b-a964-43cd-86d0-e9056800bd51> . ?r <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#plainTextMessageContent> ?v1 . FILTER(bif:contains(?v1, "'virt'")) . OPTIONAL { ?r <http://akonadi-project.org/ontologies/aneo#akonadiItemId> ?reqProp1 . } } . }

Wow ... the second is large:

qdbus org.kde.nepomuk.services.nepomukqueryservice /nepomukqueryservice/query95 queryString
select distinct ?r ?reqProp1 where { { ?r <http://akonadi-project.org/ontologies/aneo#akonadiItemId> ?reqProp1 . { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/1f280755-fb31-42ae-93c3-0d00c73de706> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b849ca47-f5cb-4a1b-8e66-f492e0c74ea1> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/e0007b88-19a8-4a18-b8fe-9f52db773429> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b2cc492d-a6c5-4bd8-b8b5-9a1220518f3c> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/796549f2-ba2e-4270-a8f6-018dbafb42dc> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b4665ccb-1d70-4e67-b968-3b6ca0a5ee40> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/2414de6b-3f9b-4636-ba7b-2de8e2ef0e89> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/abbb5463-e29e-4150-8b98-ecc80f9f13b2> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b7c9e1e8-0777-43af-9c8b-dc2653413a13> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/adebc26c-c255-4a8e-b62d-ff4afd6800c5> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/9449d58f-a9d4-42e7-b54a-7c41a299cee9> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/62830ceb-a9cc-41d5-ac9d-fc9b486a602d> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/f894f9e2-c6a0-4d33-8978-222b1e0d04b5> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/0ef02f61-0e6f-4e67-aba8-393af9d38676> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/cca75cb2-0051-45e8-80eb-ce9fadec438f> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/4236263b-f2f4-400b-9d63-5ce241958297> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b94e670a-33d3-401c-adc0-fa69456948e9> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/2fb32a8f-96f7-43b1-8f7f-bacd3b588f1d> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/896db163-f472-4f93-aea8-bdf47a29ec35> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/9a41fce4-a817-4f1b-a325-51a013b2073e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/3b45f30d-1ff4-4922-8912-73bcf74caa2d> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/bdcd11b5-0f28-44d7-9bee-8704bb05381d> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/2aa773ff-22ca-450b-827f-45fe5cdd4111> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/e3b43980-1edb-419a-85b6-bb9aeca5f521> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/0da312e1-d429-4bb7-b2f7-dfcca6e1f434> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/517601c1-5a75-4a32-87c4-a1b6bb6b977e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/f1ac4bc3-b495-482a-8504-b64b5aeeece9> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/f706cba3-d721-4267-bb9b-b1b258f21473> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/50b291a6-31a8-4308-a7c4-b9f20f3e412d> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/86dd8dab-6d90-481c-a46a-db1eab6e1394> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/e5182480-083b-4328-83e0-5f4298a65633> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/bcad280a-d239-44b0-ba10-c43efef58d6c> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/90a0b985-af1f-4de8-b66d-bafbdd7cf2e4> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/d27ff847-7ab4-41ac-a81f-cd4188f5e91c> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/d172f0c0-bfd2-435e-8cff-f3876a1cfee4> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/be863007-9da8-409f-9543-31e1f3db4ee8> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/e5891946-b160-4c26-82ab-57ffc7cd08f4> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/f095b9dc-9346-4336-8a16-7a6455230abf> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/a2463b1e-230a-4f2c-8626-03fe98e054f5> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/4b27e975-6960-4174-a3c3-7a987709f220> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/ef7d777a-00d2-41cc-be55-ccd5b3d2b784> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/14286d14-701f-4920-baf4-b8208888cc72> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/293a9f90-b217-4dac-8670-4ac571fb1b24> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/d7ec1447-aa41-4d54-9d77-5273f8a2b29e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/af253c90-59f0-4d67-b336-9a127bddfb50> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/80d220f1-ea1b-4e3c-ada4-8736e0fedd7e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/4168aaa7-315d-4463-8372-6029fcb648c3> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/9769db48-6d58-4a39-9fff-0e849e4a5a5a> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b0be5c25-9ed5-446d-b187-e061ff8e2d9e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/c9105d92-a850-4449-9539-3b5fb6f47eb0> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/0e30c8cb-ec5c-430a-ae68-e9847bca895e> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/814435a6-c710-4600-853a-9c8d69af50e3> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/9d6faf63-8ac1-4ccc-b2ed-80f5b4729214> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/b7b99ebf-4244-4bb2-8fad-6dbb6b85d587> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/9a36d0af-b4e4-4704-9be8-0c85acbb031b> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/6a7250a5-b8e1-41f3-9e87-9648962e1aad> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/db0140c8-3bcb-4316-be85-bcf1bf2dd6c9> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/5e615b02-e82f-4897-b3d2-99292e505955> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/813290d0-9a79-4df2-b32e-7fe3e6b3771f> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/4206b8e2-c53e-41f2-ac3f-0a39324bd366> . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> <nepomuk:/res/48920483-f28b-4915-a9a8-02116be5c774> . } . { ?r <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#plainTextMessageContent> ?v1 . FILTER(bif:contains(?v1, "'n810'")) . } UNION { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#isPartOf> ?v2 . ?v2 <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#plainTextMessageContent> ?v3 . FILTER(bif:contains(?v3, "'n810'")) . } . ?r a <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#Email> . } . }

Note that virtuoso-t does not consume any CPU cycles - it's just lots of memory.

And BTW: I'm using KDE 4.10.5 on openSuse 12.3, 64bit

So now I've already upgraded to KDE 4.11 and currently virtuoso-t is again using approximately 938.5 MB of memory.

Interestingly qdbus org.kde.nepomuk.services.nepomukqueryservice shows now not a single query:

/
/KDebug
/backupmanager
/datamanagement
/nepomukontologyloader
/nepomukqueryservice
/nepomukstorage
/resourcewatcher
/resourcewatcher/watch10
/resourcewatcher/watch14
/resourcewatcher/watch22
/resourcewatcher/watch6
/resourcewatcher/watch8
/servicecontrol

I killed it and it restarted at 12:50 and it used about 50MB RAM.
It's now 15:40 and the memory is already up to approximately 139.3 MB

Since 4.11 on Archlinux, virtuoso-t eats more and more memory and KMail is slow. 
dbus-qt4 org.kde.nepomuk.services.nepomukqueryservice 
/
/backupmanager
/datamanagement
/nepomukontologyloader
/nepomukqueryservice
/nepomukstorage
/resourcewatcher
/resourcewatcher/watch1
/resourcewatcher/watch2
/resourcewatcher/watch3
/resourcewatcher/watch37
/resourcewatcher/watch5
/resourcewatcher/watch6
/resourcewatcher/watch7
/resourcewatcher/watch8
/resourcewatcher/watch9
/servicecontrol

I updated from openSUSE 12.3 (KDE 4.10.5) to openSUSE 13.1 (KDE 4.11) and now virtuoso-t keeps eating memory (to more than 6 GB and eventually hangs everything). I only use nepomuk for email indexing (because Kmail requires). The size of all mail boxes are about 7GB. I hope it dose not need 7GB memory to index 7GB emails? Anyway, I have to use a script to monitor the memory use and kill virtuoso-t as suggested.

$ qdbus org.kde.nepomuk.services.nepomukqueryservice
/
/KDebug
/backupmanager
/datamanagement
/nepomukontologyloader
/nepomukqueryservice
/nepomukstorage
/resourcewatcher
/resourcewatcher/watch1
/resourcewatcher/watch2
/resourcewatcher/watch3
/resourcewatcher/watch5
/resourcewatcher/watch6
/servicecontrol

kde 4.11.4  x64
memory still leaking(and it's leak fast! ~30Mb per minute), i tried:
$ akonadictl fsck
$ akonadictl vacuum
$ nepomukcleaner
it didn't help

qdbus org.kde.nepomuk.services.nepomukqueryservice
/
/backupmanager
/datamanagement
/nepomukontologyloader
/nepomukqueryservice
/nepomukstorage
/resourcewatcher
/resourcewatcher/watch1
/resourcewatcher/watch14
/resourcewatcher/watch15
/resourcewatcher/watch2
/resourcewatcher/watch3
/servicecontrol

kde 4.11.5  x64 still leaking...

in addition to 16GB RAM I create 28GB swap and allowed nepomuk to work few weeks( also i set ulimit to 12Gb in order to don't freeze my system) - look like it fix itself...

Don't get me wrong, I don't want to sound cynical but I have no 16GB RAM, I have a laptop with 2GB and the reason I use Akonadi and Nepomuk is TO FIND STUFF FAST, not wait some weeks.
Is that a wrong expectation?

On my system, I now have nepomuk enabled and it seem to work, however the contact auto completion in KMail is now not working. If I switch nepomuk off, the autocompletion is working again, but I have no categories in KAddressbook... Aaaaaaahhhhhh.....
So either Address categories OR address autocompletion.

Thank you for taking the time to file a bug report.

The Nepomuk project is no longer included in the KDE Software Compilation. With Plasma 5, we have replaced most of the underlying technology with Baloo and other components. Hopefully this will have addressed your concern.

We encourage you to try out Plasma 5 (+Baloo) and let us know if your problem persists.