[opensuse-kde] akonadi eats CPU after suspend
Hi, On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend. Most of the times I have two akonadi instances using each one about one CPU, plus there is some mysql instance, related to akonadi, that eats some extra 30 or 40% of cpus. This slows down the computer very much. Usually "akonadictl restart" fixes the problem. I've looked on google for some more info, but I haven't found anything. I use kmail with only me work emain via imaps Plus I did connect my google address book to KAdressBook (I would like to remove it, but I can't find where) If relevant, I use telepathy with Hangout. Is there a place with some log I can check or something like this or a workaround? Ciao, Francesco -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data martedì 26 aprile 2016 17:04:27 CEST, Francesco Montesano ha scritto: Hello,
On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend.
Can you post your PIM stack versions? I haven't seen this in a while on my laptop. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Hi, 2016-04-26 17:07 GMT+02:00 Luca Beltrame <lbeltrame@kde.org>:
Can you post your PIM stack versions? I haven't seen this in a while on my laptop.
I hope this is what you want: kdepim: 15.12.3-2.1 kdepim-runtime: 15.12.3-2.1 kdepimlibs4: 4.14.10-1.2 kio-pimlibs: 15.12.3-1.1 libKF5PimTextEdit5: 15.12.3-1.1 libbaloopim4: 4.14.3-2.2 libkdepim: 15.12.3-2.1 libkdepimlibs4: 4.14.10-1.2 kmailtransport: 15.12.3-1.1 kmail5: version 15.12.3-2.1 The Kmail application: kmail2 5.1.3 Using: KDE Frameworks 5.21.0 Qt 5.5.1 (built against 5.5.1) The xcb windowing system They all come from repo-oss. I also use kde-extra repo. Ciao, Francesco
-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Tuesday, 26 April 2016 17:04:27 EEST Francesco Montesano wrote:
Hi,
Hi,
On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend.
Most of the times I have two akonadi instances using each one about one CPU, plus there is some mysql instance, related to akonadi, that eats some extra 30 or 40% of cpus.
I use kmail with only me work emain via imaps Plus I did connect my google address book to KAdressBook (I would like to remove it, but I can't find where)
Akonadi is known to loop forever updating resources such as remote .ics files from Google, if you set them read-only. Perhaps this is a similar problem in your case? You may remove the address book from the left column in KAddressBook or by using akonadiconsole.
Ciao,
Francesco -- Regards, Peter -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi, 2016-04-26 18:00 GMT+02:00 auxsvr <auxsvr@gmail.com>:
On Tuesday, 26 April 2016 17:04:27 EEST Francesco Montesano wrote:
Hi,
Hi,
On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend.
Most of the times I have two akonadi instances using each one about one CPU, plus there is some mysql instance, related to akonadi, that eats some extra 30 or 40% of cpus.
I use kmail with only me work emain via imaps Plus I did connect my google address book to KAdressBook (I would like to remove it, but I can't find where)
Akonadi is known to loop forever updating resources such as remote .ics files from Google, if you set them read-only. Perhaps this is a similar problem in your case? You may remove the address book from the left column in KAddressBook or by using akonadiconsole.
I had my google calendar and I removed it, so it's not that. About removing the address book: if I right click on my account entry, I see a "delete address book". Does it only deletes the address book from the akonadi list or also tells google about deleting stuff? Fra
Ciao,
Francesco -- Regards, Peter -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi, 2016-04-26 18:08 GMT+02:00 Francesco Montesano <franz.bergesund@gmail.com>:
On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend.
It did happen again. This time I've looked into xsession-error and journalctl. While akonadi occupies the cpu xsession-error get the following string many times a second: posting retrieval request for item 28933 there are 1 queues and 0 items in mine request for item 28933 still pending - waiting processing retrieval request for item 28933 parts: ("RFC822") of resource: "akonadi_akonotes_resource_0" akonadiagentbase_log: Item does not provide part "RFC822" continuing request for item 28933 succeeded In journalctl I can't see anything about akonadi. Just awake messages from various units, some complaints and error from telepathy and pam. Attached you can see the first few minutes after awaking. Ciao, Fra
Hi, Little update 2016-04-27 17:15 GMT+02:00 Francesco Montesano <franz.bergesund@gmail.com>:
Hi,
2016-04-26 18:08 GMT+02:00 Francesco Montesano <franz.bergesund@gmail.com>:
On my TW machine, since a couple of weeks, akonadi behaves badly after resuming from suspend.
It did happen again. This time I've looked into xsession-error and journalctl. While akonadi occupies the cpu xsession-error get the following string many times a second:
posting retrieval request for item 28933 there are 1 queues and 0 items in mine request for item 28933 still pending - waiting processing retrieval request for item 28933 parts: ("RFC822") of resource: "akonadi_akonotes_resource_0" akonadiagentbase_log: Item does not provide part "RFC822" continuing request for item 28933 succeeded
I get this also when akonadi is not sucking all the CPU Fra -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 27 aprile 2016 17:18:41 CEST, Francesco Montesano ha scritto:
I get this also when akonadi is not sucking all the CPU
It's likely unrelated then. Installing debug symbols and providing a backtrace to the 100% CPU process would be helpful in finding the issue. But before that, does this also occur on a network loss? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Hi, 2016-04-27 17:24 GMT+02:00 Luca Beltrame <lbeltrame@kde.org>:
In data mercoledì 27 aprile 2016 17:18:41 CEST, Francesco Montesano ha scritto:
I get this also when akonadi is not sucking all the CPU
It's likely unrelated then. Installing debug symbols and providing a backtrace to the 100% CPU process would be helpful in finding the issue.
Whould they be the -debuginfo version of the packages I've listed yesterday in my mail? How would I provide a backtrace in that case?
But before that, does this also occur on a network loss?
Not that I've noticed. Also it doesn't happen after every resume. Ciao, Fra
-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 27. April 2016, 17:33:46 CEST schrieb Francesco Montesano: Hi,
Whould they be the -debuginfo version of the packages I've listed yesterday in my mail? How would I provide a backtrace in that case?
You attach gdb to the running process and enter bt on the commandline. Something like: Use top in konsole in order to identify the cpu consuming process and its PID (process id). Use gdb in konsole and attach to the running process: km82rt@sony-01:~> gdb -p 3232 GNU gdb (GDB; %maintenance_distribution) 7.9.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 3232 [...] (gdb) bt #0 0x00007f6a759b3bbd in poll () at /lib64/libc.so.6 #1 0x00007f6a73d49e64 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007f6a73d49f7c in g_main_context_iteration () at /usr/lib64/ libglib-2.0.so.0 #3 0x00007f6a764f7d6c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #4 0x00007f6a7649ed53 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/ libQt5Core.so.5 #5 0x00007f6a764a68f6 in QCoreApplication::exec() () at /usr/lib64/ libQt5Core.so.5 #6 0x000000000047b3b2 in main () (gdb) The output from the 'bt' command is relevant. Regards --martin konold -- Dipl.-Physiker Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Registergericht: Amtsgericht Stuttgart PR 126 Firmensitz: Adolfstraße 23, 70469 Stuttgart fon: 0711 67400963 fax: 0711 67400959 email: martin.konold@erfrakon.de http://www.erfrakon.de -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Mittwoch, 27. April 2016 17:24:04 CEST Luca Beltrame wrote:
In data mercoledì 27 aprile 2016 17:18:41 CEST, Francesco Montesano ha scritto:
I get this also when akonadi is not sucking all the CPU
It's likely unrelated then. Installing debug symbols and providing a backtrace to the 100% CPU process would be helpful in finding the issue.
I had the same problem. backtrace attached. there are more than 80 threads, and it seems all but thread 34 are waiting in poll(). Thread 34 is in Akonadi::Server::Connection::readCommand()
But before that, does this also occur on a network loss?
no. Just with disconnecting or reconnecting the network it did not happen. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Hi,
On Mittwoch, 27. April 2016 17:24:04 CEST Luca Beltrame wrote:
It's likely unrelated then. Installing debug symbols and providing a backtrace to the 100% CPU process would be helpful in finding the issue.
I finally managed to get the bad guys. Attached are the tracebacks of the two akonadiserver processes using about 1 CPU each
But before that, does this also occur on a network loss?
No. However it seems that: after a reboot everything works fine for some suspend-resume cycle. Then something happens and akonadi begins miss-behaving after at every resume. Let me know if you need more info and/or if I should file a bug at kde Ciao, Francesco
In data martedì 3 maggio 2016 00:22:40 CEST, Francesco Montesano ha scritto:
I finally managed to get the bad guys. Attached are the tracebacks of the two akonadiserver processes using about 1 CPU each
Thanks, those may be helpful in finding the root cause. Now you see you mention *two* processes for "akonadiserver". Normally there should be just one and no more, IIRC. What happens if you kill either one? -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Hi Luca, 2016-05-03 7:20 GMT+02:00 Luca Beltrame <lbeltrame@kde.org>:
In data martedì 3 maggio 2016 00:22:40 CEST, Francesco Montesano ha scritto:
I finally managed to get the bad guys. Attached are the tracebacks of the two akonadiserver processes using about 1 CPU each
Thanks, those may be helpful in finding the root cause. Now you see you mention *two* processes for "akonadiserver". Normally there should be just one and no more, IIRC. What happens if you kill either one?
When it locks I see two processes in htop using about 1 cpu each. If I filter akonadiserver I see some 20 instances (see attachment). Apparently htop shows all the threads, so I'm not sure if the two on top are two processes or two threads of the same process. Next time I see the issue I'll investigate and let you know. Ciao, Fra
-- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Hi, 2016-05-06 10:10 GMT+02:00 Francesco Montesano <franz.bergesund@gmail.com>:
[...]
Thanks, those may be helpful in finding the root cause. Now you see you mention *two* processes for "akonadiserver". Normally there should be just one and no more, IIRC. What happens if you kill either one?
it happened again and checked. * ps and top show only one akonadiserver process, * htop shows two very demanding processes as in the screenshot attached to my previous mail, one of which is the one that I also see in ps/top So I guess that htop shows also child threads. Of the two processes in htop showing a lot of activity, I've killed the one that is *not* shown by ps/top. The main akonadiserver process went back to normal. Ciao, Fra -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data venerdì 6 maggio 2016 20:48:25 CEST, Francesco Montesano ha scritto:
Of the two processes in htop showing a lot of activity, I've killed the one that is *not* shown by ps/top. The main akonadiserver process went back to normal.
Is also the system working normally after this? I think a second process is spawned after suspend, but I've never ever seen this behavior myself. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Hi, 2016-05-08 18:54 GMT+02:00 Luca Beltrame <lbeltrame@kde.org>:
In data venerdì 6 maggio 2016 20:48:25 CEST, Francesco Montesano ha scritto:
Of the two processes in htop showing a lot of activity, I've killed the one that is *not* shown by ps/top. The main akonadiserver process went back to normal.
Is also the system working normally after this? I think a second process is spawned after suspend, but I've never ever seen this behavior myself.
Kmail works fine afterwards. However it's not the only akonadiserver is not the only thing that locks after suspend. Plasmashell locks quite frequently, but before reporting I need to check if this happens only after disconnecting external screens (I haven't reported this since I know that multiscreen at the moment doesn't work properly) Yesterday I got krunner locked because of baloo. If it happens again I'll report at bugs.kde Ciao, Fra
-- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (5)
-
auxsvr -
Francesco Montesano -
Luca Beltrame -
Martin Koller -
Martin Konold