Re: kontact suddenly dead slow

"O. Sinclair" <[email protected]>
Newsgroups gmane.comp.kde.users.pim
Message-ID <[email protected]>
On 14/10/2013 18:22, Administrators ITSEF wrote:
> 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!
>

Have you tried starting just KMail, not Kontact, to see if it behaves 
the same? I have had issues with Addressbook causing Kontact to go 
unresponsive. Further, check your "tags", I had multiple blank tags and 
they can also slow down Kontact.

Sinclair
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.