Bug 223439

Summary: Item listing for folders slow
Product: [Applications] kmail2 Reporter: Thomas McGuire <mcguire>
Component: miscAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: Martin
Priority: VHI Keywords: akonadi-ports-regression
Version: 1.99.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Bug Depends on:    
Bug Blocks: 223438    

Description Thomas McGuire 2010-01-19 19:22:21 UTC
Version:           1.99.0 (using Devel)
OS:                Linux
Installed from:    Compiled sources

When selecting a folder, it takes a long time until the message list is populated.
This is even minutes for a folder with only a few hundred messages.

Akonadiconsole doesn't have this problem.
Comment 1 Thomas McGuire 2010-01-26 18:17:55 UTC
It seems that every item fetch job that fetches the headers takes insanely long. The same happens in KMailCVT, which fetches the headers to get the message IDs for duplicate checking.

mysql uses 120% CPU during that time, according to top.
Comment 2 Thomas McGuire 2010-02-02 22:14:25 UTC
The problem seems to be the part query in FetchHelper::parseStream().

This is an example debug output, with some timing info:

2010-02-02T21:57:55 Executing part query. 
SELECT PimItemTable.id, PartTable.name, PartTable.data, PartTable.version, PartTable.external FROM PimItemTable, PartTable WHERE ( PimItemTable.id = PartTable.pimItemId AND ( PartTable.name IN ( :0, :1 ) ) AND ( PimItemTable.id >= :2 ) AND collectionId = :3 ) ORDER BY PimItemTable.id ASC

 ":0" QVariant(QString, "COLLECTIONID")
 ":1" QVariant(QString, "PLD:HEAD")
 ":2" QVariant(qlonglong, 1)
 ":3" QVariant(qlonglong, 18882)

2010-02-02T21:58:23 Part query done, now building response.

Executing that query in the DB console has the same slowness.
Displaying the part table in the DB browser also takes about a minute here, with ~100k entries in there.
Comment 3 Thomas McGuire 2010-02-02 22:18:41 UTC
> "Akonadiconsole doesn't have this problem."

Not sure if that is really the case, I'll check again.
Comment 4 Thomas McGuire 2010-02-03 12:28:24 UTC
For some strange reason, the problem disappeared all of a sudden.
Where "all of a sudden" means after disabling some resources, restarting Akonadi a couple of times and even killing Akonadi + mysql once or twice.

For tracking down this problem, enabling the MySQL slow log might help.
See $KDEDIR/share/config/akonadi/mysql-global.conf, the settings log_slow_queries and long_query_time.

The slow log will appear at $HOME/.local/share/akonadi/db_data/mysql.slow
Comment 5 Thomas McGuire 2010-02-03 12:48:07 UTC
Torgny made a log at http://www.nyblom.org/pub/kde/mysql.slow, but I don't think it shows the problem - the query of comment#2 is not in there (grep for "ORDER BY Pimitemtable.id").
Comment 6 Thomas McGuire 2010-02-03 12:58:21 UTC
I can reproduce the problem again, after adding an IMAP resource:

# Time: 100203 12:56:26
# User@Host: [trunk] @ localhost []
# Query_time: 155  Lock_time: 0  Rows_sent: 33  Rows_examined: 968385
SELECT PimItemTable.id, PartTable.name, PartTable.data, PartTable.version, PartTable.external FROM PimItemTable, PartTable WHERE ( PimItemTable.id = PartTable.pimItemId AND ( PartTable.name IN ( 'COLLECTIONID', 'PLD:HEAD' ) ) AND ( PimItemTable.id >= 1 ) AND collectionId = 15 ) ORDER BY PimItemTable.id ASC;
Comment 7 Thomas McGuire 2010-02-03 12:59:13 UTC
> I can reproduce the problem again, after adding an IMAP resource:

The folder I opened was a local maildir folder, not an IMAP folder.
Comment 8 Thomas McGuire 2010-02-03 13:05:45 UTC
The query from comment #6 is executed twice when selecting a folder, doubling the delay.
Comment 9 Thomas McGuire 2010-02-03 14:01:30 UTC
As mentioned, just displaying the parttable in Akonadiconsole is also slow:

# User@Host: [thomas] @ localhost []
# Query_time: 27  Lock_time: 0  Rows_sent: 28918  Rows_examined: 28918
SELECT `id`, `pimItemId`, `name`, `data`, `datasize`, `version`, `external` FROM parttable;
Comment 10 Thomas McGuire 2010-04-12 18:50:34 UTC
Doesn't happen right now, I'll reopen when it happens again.
Comment 11 Martin Steigerwald 2015-09-08 19:35:08 UTC
Thanks, Thomas. Closing. Reopen when it happens again.