Bug 757416

Summary: akonadi (mysqld) causes excessive wakeups
Product: [Fedora] Fedora Reporter: Dmitry Torokhov <dmitry.torokhov>
Component: akonadiAssignee: Kevin Kofler <kevin>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: jreznik, kevin, ltinkl, rdieter, smparrish, than
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 15:54:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dmitry Torokhov 2011-11-26 22:38:36 UTC
Description of problem:

After updating from F15 to F16 and doing KDEPIM conversion to Akonadi resources I observe mysqld instance spawned by akonadi causing excessiwe wakeups on the system. Even when complete idle (kogranizer/kmail are closed; IMAP resources are configured to go offline on kmail shutdown) I observe in powertop:

0.9 ms/s      17.9        Process        /usr/libexec/mysqld --defaults-file=/home/dtor/.local/share/akonadi//my

Quite often wakeups spike to 39-40 wakeups/second.

Version-Release number of selected component (if applicable):
akonadi-1.6.2-2.fc16.1.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Boot the system?
2.
3.
  
Actual results:


Expected results:
Number of wakeups from akonadi./mysql should be under 1/sec.

Additional info:
I have quite large number of e-mails in IMAP accounts (over 100k).

Comment 1 Kevin Kofler 2011-11-27 02:32:50 UTC
I wonder whether those wakeups are really Akonadi's fault and not MySQL's…

Comment 2 Dmitry Torokhov 2011-11-27 03:28:03 UTC
That could be but since akonadi is what brings mysqld in it's the one that gets the blame.

Comment 3 Rex Dieter 2011-11-27 15:21:13 UTC
For comparision, powertop reports akonadi/sqlite not  even in the top 20 for wakeups, akonadi/mysql was 8 with:

609.1 µs/s      10.9        Process        /usr/libexec/mysqld --defaults-file=/home/rdieter1/.local/share/akonadi//mysql.conf --

ie, approx 10.9 wakeups/second

So, if you value resource usage and wakeups (over performance), I'd suggest you trying switching akonadi to use a sqlite backend instead:

systemsettings->akonadi configuration->akonadi server configuration(tab)

and click 'restart akonadi' button


Another item to consider is to disable nepomuk strigi indexing (at the cost of reduced functionality when/if doing searches on email):
systemsettings->desktop search->basic settings(tab)
*uncheck* 'enable strigi desktop file indexer'

Comment 4 Dmitry Torokhov 2011-11-27 21:48:37 UTC
(In reply to comment #3)
> For comparision, powertop reports akonadi/sqlite not  even in the top 20 for
> wakeups, akonadi/mysql was 8 with:
> 
> 609.1 µs/s      10.9        Process        /usr/libexec/mysqld
> --defaults-file=/home/rdieter1/.local/share/akonadi//mysql.conf --
> 
> ie, approx 10.9 wakeups/second
> 
> So, if you value resource usage and wakeups (over performance), I'd suggest you

No I can't say I am willing to take even bigger performance hit as at the moment Kmail2 is not really usable for me (compared to Kmail1 that I had with F15).

> trying switching akonadi to use a sqlite backend instead:

Also, don't akonadi guys advise against using sqlite backend in their FAQ?

> 
> systemsettings->akonadi configuration->akonadi server configuration(tab)
> 
> and click 'restart akonadi' button
> 
> 
> Another item to consider is to disable nepomuk strigi indexing (at the cost of
> reduced functionality when/if doing searches on email):
> systemsettings->desktop search->basic settings(tab)
> *uncheck* 'enable strigi desktop file indexer'

That's been turned off since the original install of F11 (or 10? I don't recall). As I mentioned I do not really use indexing, I generally know where stuff is and otherwise grep is always there for me.

So I see:

 3188 dtor      20   0  755m 120m  15m R 87.4  3.1 328:01.71 akonadi_nepomuk                                                  

That's tad too much, don't you think?

Thanks.

Comment 5 Kevin Kofler 2011-11-27 22:03:32 UTC
> Also, don't akonadi guys advise against using sqlite backend in their FAQ?

Yes, they do. That's why it's not the default.

Comment 6 Rex Dieter 2011-11-28 14:56:09 UTC
In fairness, the advice is based mostly for performance reasons.  It's not that sqlite is *bad* per-se, I mean it is the default used on some other platforms, like meego (and friends).

Comment 7 Fedora End Of Life 2013-01-16 14:37:59 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Fedora End Of Life 2013-02-13 15:54:09 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.