Bug 291948 - [Nepomuk] The amount of resources needed to index contacts are insane.
Summary: [Nepomuk] The amount of resources needed to index contacts are insane.
Status: RESOLVED DUPLICATE of bug 289932
Alias: None
Product: nepomuk
Classification: Miscellaneous
Component: general (show other bugs)
Version: 4.8
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-19 13:38 UTC by Alejandro Nova
Modified: 2012-02-15 18:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alejandro Nova 2012-01-19 13:38:02 UTC
Version:           4.8 (using Devel) 
OS:                Linux

If I have 1,500 contacts, Nepomuk will take more than 5 hours to index only the contacts, without any involvement of Strigi or deep indexing features. This with Virtuoso running at 100%.

Reproducible: Always

Steps to Reproduce:
1. Add the Facebook resource and the Google Contacts resource.
2. Let them populate your Contacts, your Birthdays and your Events.
3. Run Nepomuk in an isolated setup (clean database, no Strigi indexing, no mail indexing) and Akonadi with at least the Facebook, Google, Birthdays and some mail resources (if available).

Actual Results:  
Nepomuk takes hours to index contacts.

Expected Results:  
Nepomuk takes a few minutes to index contacts.

Strigi isn't doing anything. CPU usage is more than 100% (2 cores). Also, nepomukstorage is consuming 200 MB of RAM and dbus-daemon is eating 160 MB of RAM, after indexing only contacts, with everything else disabled in Nepomuk.
Comment 1 Alejandro Nova 2012-01-19 13:45:58 UTC
This is quite telling.

http://ompldr.org/vY2Mzdw

After indexing contacts, memory usage figures are as follows.

nepomukstorage: 210,884 KB
dbus-daemon: 163,620 KB
virtuoso-t: 163,524 KB
akonadi_facebook_resource: 87,704 KB
akonadi_nepomuk_feeder: 82,972 KB.
Comment 2 Alejandro Nova 2012-02-15 18:01:16 UTC

*** This bug has been marked as a duplicate of bug 289932 ***