[Kde-pim] KDE 4.8, Virtuoso at 130% CPU for hours now - how can I help find the issue?

[Anders Lund]

Søndag den 29. januar 2012 18:46:49 Georg C. F. Greve skrev:
> On Saturday 28 January 2012 17.55:11 Christian Mollekopf wrote:
> > I'm aware of those problems and will try to fix them. The pim sprint will
> > be  one opportunity for this. So far I was busy getting it to work
> > basically, I'm sorry that it still kinda sucks (It wasn't initially
> > apparent to me how much it sucks).
> 
> Actually I suspect that Nepomuk is responsible for much of the grief people
> directed at Akonadi, because it is typically not easy for the user to detect
> which component is actually causing the issues.

I had no problems with nepomuk since some months, until upgrading kdepim. So I 
have to disagree. I imported about 10000 messages in chunks yesterday, and the 
biggest chunks (3-4000 messages) caused hours of akonadi/nepomuk activity, and 
eventually nepomuk went into some sort of spin - stopping it and starting it 
again made that go away. But that was initiated by akonadi. So maybe more 
complex than just blaming one of the two?

> Also, while it is known that Nepomuk indexing can cause high loads and will
> then slow down the entire machine and cause massive load for virtuoso, which
> then often gets attributed to Akonadi, there are also some other
> interactions when Nepomuk is not indexing.

nepomuk is running at lowest possible priority, and doesn't really disturb on 
my system. Under normal circumstances, the nepomuk indexer and other services 
works fine. But once in broken state, it have to be restarted, and often I have 
to restart KDE to get nepomuk search back in a functional state.

During normal workflow, just fetching mail every hour, > 100 messges at the 
time, does not harm anything. Its the big operations that cause problems, at 
least here.

> These cause Nepomuk to "stand on the feet of Akonadi" causing sluggish
> response issues in Kontact for me, where sometimes fetching a message can
> take dozens of seconds, occasionally it'll hang for a very long time.

again, look at the process table, all the nepomuk processes are running at low 
priority.

> Where that bottleneck originates, I do not know.
> 
> But when Nepomuk is turned off, I virtually never see any of these issues,
> and Akonadi & Kontact are fast and responsive even on a fairly old laptop.

Looks like akonadi does something wrongly with nepomuk, to me at least. 

> Naturally not having an address book kind of sucks for a PIM client, so in
> the end I typically end up enabling Nepomuk again, and then again Akonadi
> becomes slow & sluggish on occasion.

I can use kaddressbook, but autocompletion is not working with kdepim 4.8, for 
me at least, so the #2 way of getting something into the To: and Cc: fields is 
missing (#1 is pressing R, A, F or L ;)

> Looking at this would be a good activity for the PIM Sprint in two weeks.

+1

Anders

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/