kontact suddenly dead slow

Hi all,

I've tried searching the list archives to see whether something like  
this has been discussed previously, but came up empty.  
"akonadiserver", "performance", "slow" etc. are not good search terms,  
it seems - and I just cannot think of better ones...

Anyway, I ran into the following problem that I hope to find some help for:

Situation: An existing user account is to be migrated from Kontact e35  
(Kolab) under Kubuntu 10.04 to 4.11.2 under Kubuntu 13.10 (beta).

Steps:
To avoid upgrade problems, I delete the following before logging into  
the new KDE for the first time:
In $HOME: .cache, .dbus, .dmrc and .kde
In $HOME/.local/share: akonadi, gvfs-metadata, telepathy and webkit
In $HOME/.config: akonadi, autostart, dconf, enchant, gtk-2.0, ibus,  
pulse, Trolltech.conf, upstart, user-dirs.dirs and user-dirs.locale
This selection was based on "if I don't know what it's for, out it goes".

Also, the account is moved from an NFS home directory to a local home  
directory - I've already noticed that NFS is only poorly supported by  
the new technologies that are currently used in KDE.

I then log in, fire up Kontact and begin adding accounts. The first  
account is a Kolab V2 account. After adding it, it takes some time  
until all indexing is finished and the machine settles and all seems  
well.

The second account is also a Kolab V2 account, but for a different  
user. I add it - like the first one - using the Account Wizzard.  
Initially, all seems well. Then, after a while, the CPU (an i3) goes  
haywire - top reveals that kontact uses 20-30% CPU, akonadiserver uses  
some 40-50% CPU and mysqld another 50-60%. While the machine itself  
remains amazingly reponsive, Kontact (KMail) grinds to a halt. Trying  
to view a message takes a minute. Trying to open up folder properties  
takes up to two minutes - basically, Kontact is unusable and I didn't  
even try to add the third account...

Quitting Kontact in this situation does not always work and often  
results in a crash - or I have to kill it outright. In any case, upon  
a re-start of Kontact, it takes a few seconds before the above  
situation is reached again and the kontact, akonadiserver and mysqld  
processes start happily eating CPU again.

I have already tried disabling email indexing and file indexing  
altogether, but that does not change anything - as soon as I start  
Kontact, those three processes go crazy and Kontact more or less  
immediately becomes unusable (I might manage to view one or two  
messages before anything grinds to a halt - I actually have to use the  
webmail on the Kolab server to write this...).

Hence, my question:
Does anyone out there have an idea as to how I could debug and resolve  
this situation - preferably without having to wipe everything and go  
through the full Kontact configuration again (I already did that once)?

This is especially pressing for me, as this Kontact set-up is a pilot  
to investigate whether Kontact has matured enough to finally resolve  
(at least most of) the problems we had with the e35 version (crashes,  
loss of e-mail, loss of events, ghostmails - stuff like that).  
Featurewise, I liked what I saw so far, but this one could be a  
show-stopper...

Hence, I'd be very grateful for any hints, RTFMs, etc. how to get this  
sorted and keep Kontact working!

Thanks in advance,

Thomas

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users