Bug 201086 - kontact high cpu load > 50%
Summary: kontact high cpu load > 50%
Status: RESOLVED WORKSFORME
Alias: None
Product: kontact
Classification: Applications
Component: general (show other bugs)
Version: 0.1
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-22 10:52 UTC by Alin M Elena
Modified: 2010-10-30 20:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
ltrace log for kontact high cpu load (137.65 KB, application/octet-stream)
2009-07-22 10:55 UTC, Alin M Elena
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alin M Elena 2009-07-22 10:52:16 UTC
Version:           1.12.0 (using 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2)) "release 142", KDE:KDE4:Factory:Desktop / openSUSE_11.1)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.27.23-0.1-default

Randomnly kontact starts using a lot of cpu usually more than 50%.
I did an ltrace on the process, I hope may be of some help.

Alin
Comment 1 Alin M Elena 2009-07-22 10:55:11 UTC
Created attachment 35537 [details]
ltrace log for kontact high cpu load
Comment 2 Will Stephenson 2009-07-22 11:03:02 UTC
Please give a list of which resource types you have registered in Contact and Calendar modules, and which account types you use in kmail.
Comment 3 Alin M Elena 2009-07-22 11:09:00 UTC
Hi,

kmail are imap accounts 2 google 2 other
resources:
*Birthdays
*2 calendar in remote file resources
*1 akonadi resource
 ** with some previous imported resources when migration to akonadi was done
 ** 3 resources that were added to akonadi
  all of them are calendars in remote files

Contact 
  Default address book

Alin
Comment 4 Alin M Elena 2009-07-22 12:33:27 UTC
got rid of the akonadi_resource from kontact

attached with gdb here is the bt
(gdb) bt
#0  0x00007fd5da24b386 in poll () from /lib64/libc.so.6
#1  0x00007fd5d59ac768 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007fd5d59aca8b in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fd5dc0fdd3f in QEventDispatcherGlib::processEvents (this=0x60d870, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327
#4  0x00007fd5dae89fef in QGuiEventDispatcherGlib::processEvents (this=0x266dfb0, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202
#5  0x00007fd5dc0d31d2 in QEventLoop::processEvents (this=<value optimized out>, flags={i = -391892992}) at kernel/qeventloop.cpp:149
#6  0x00007fd5dc0d35a4 in QEventLoop::exec (this=0x7fffe8a43040, flags={i = -391892912}) at kernel/qeventloop.cpp:201
#7  0x00007fd5dc0d5894 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#8  0x0000000000404995 in _start ()
Comment 5 Will Stephenson 2009-07-22 12:49:43 UTC
That's just the even toop.  Try disabling resources methodically to isolate the problem to one resource. Also try running kmail and korganizer and kaddressbook standalone.
Comment 6 Christophe Marin 2009-11-16 15:44:39 UTC
So? can we get feedback about this report please.
Comment 7 Bruno Léon 2009-11-20 21:36:44 UTC
Hello,

I can confirm this bug in karmic using kde 4.3 fromm ppa.
I have only one account configured as Disconnected IMAP of a kolab server.

The problem is actually with korganizer because if I kill it the CPU goes down to standard usage. Korganizer is launched like this by kontact:
/usr/bin/korgac -icon korgac

Futhremore closing kontact does not close korgnaizer so once you launched kontact once, you have to kill KOrgnaizer to be able to use your machine correctly.
Comment 8 mrdocs 2010-03-28 21:31:04 UTC
I suspect this is gone in 4.4.0+
Comment 9 Christophe Marin 2010-03-28 21:48:12 UTC
Changing the bug status as discussed on irc.
Comment 10 Rigo Wenning 2010-10-30 20:45:06 UTC
Regression in KDE PIM 4.4.5 with akonadi and if a mail-resource is added to akonadi. In this case, the kontact process consumes 98% of available I/O bandwidth thus slowing the whole system to near unresponsiveness. 

Blame nepomuk and its unefficiencies. But the process being visible doing the I/O in iotop is kontact.