[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KDE 4.8, Virtuoso at 130% CPU for hours now - how can I help find the issue?
From:       Anders Lund <anders () alweb ! dk>
Date:       2012-01-29 18:27:42
Message-ID: 3047374.2DWKDtKQnx () katja
[Download RAW message or body]

S=F8ndag 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 wi=
ll
> > 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 peop=
le
> directed at Akonadi, because it is typically not easy for the user to det=
ect
> which component is actually causing the issues.

I had no problems with nepomuk since some months, until upgrading kdepim. S=
o 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 i=
t =

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 wi=
ll
> then slow down the entire machine and cause massive load for virtuoso, wh=
ich
> 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 servic=
es =

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, a=
t =

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@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]