| Summary: | Slow mark as read and folder loading | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | András Manţia <amantia> |
| Component: | Maildir Resource | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | flyser42, heri+kde, kevin.kofler |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Unread issue fixed. The other one has two causes: - disk IO bottleneck, as the maildir resource reads the headers from all the files - maildir also creates one create job per mail, but only sends this to the server after all headers were read. - maildir resource keeps the read headers in memory The above results is first high IO load in the resource, then high CPU load in the server and the database process, then high IO and CPU load in the database. This also causes high memory usage by the maildir resource if the read folder contains a lot of files. Mark as read should be faster now. KMail from kdepim 4.8.4 takes about 2 minutes to process my main maildir folder (currently at 109900 messages). kdepim 4.4.x was able to do it in a few seconds. (To clarify: "process" as in "load so that it can actually display message contents". First it takes a few seconds to show the message list, and then some more time to actually be able to display contents, totaling to ~2 minutes.) If you see the messages in the list in a few seconds, then it is not the resource that is slow. It might be the messagelist reorganizing the items (it can be REALLY slow for large folders with lots of unread mails or large threads and it depends on how it is configured: sort order, threading, view, etc.). I also experience the slow-mark-as-read issue when just viewing an email on KDE 4.8.5 / Ubuntu Precise 12.04. My client is configured to mark emails as read right when it displays them. This, however, has a significant delay (most noticable on my netbook) - probably because the changes need to be synced from Kontact to Akonadi. Sometimes it happens that I already switched to other folders to read the next batch of unread mails, but the folders are still displayed in Kontact as containing unread items. It will take a while (several seconds to a minute, maybe) for Kontact to show the correct status. Also the folder status does not always resemble the status of the emails in the email list - sometimes I read all emails, but the folder list still displays the folder as containing X unread items. Sometimes the delay (for syncing Kontact with Akonadi) is so long, that Akonadi started the next sync-with-IMAP-server operation in the background, which will cause the read status to be reset to that on the server (i.e. unread). Then I have to go again through the folders and mark emails as read manually. This usually does not affect all folders (probably because Akonadi also already synced some of my mails back up to the IMAP-server), but it is still annoying and confusing. Regarding the slow folder display: For me that stems from Kontact having to fetch the mails from Akonadi and then collate them into threads. Some time ago I created a suggestion / wishlist-bug on that matter: Fetching mails faster: bug #311781 Faster thread collation: bug #311780 (In reply to comment #6) > Also the folder status does not always resemble the status of the emails in > the email list - sometimes I read all emails, but the folder list still > displays the folder as containing X unread items. What I meant with that: The status displayed in the email list sometimes differs from the number of unread messages that the folder list displays for this folder. I.e. I am irritated by the folder list displaying 1 (e.g.) unread email, but I cannot find any unread email in the folder and the "+" shortcut does not jump to an unread email either. Only after a delay of a few seconds the folder list shows the correct number. This bites me as well when marking a folder with 17k messages on my own IMAP server as read. Any update on this? This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months. Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input. |
I added a new maildir resource and set it to my Mail folder. This resulted in all mails appearing as unread. Now if I click on a folder with many mails (3000 to 30000), it takes even minutes to load. This is somewhat expected as KMail's message list is slow as well. The problem appears when I try to mark them as read (right click on a folder, Mark all Mails as Read). This is also slow, and after the messages are marked as read, the resources starts to fetch again all the mails. I get lots of akonadi_maildir_resource_0 (0x884c90) 70850 UID FETCH 226252 FULLPAYLOAD CACHEONLY ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE) fetches (with the UID increasing). If I attach the debugger to the resource, it shows it is busy inside MaildirResource::itemChanged. The changed part is the FLAGS part, that should be because of the Mark as Read. The code goes through this part then: if ( mSettings->readOnly() || !payloadChanged ) { changeProcessed(); <---- here return; } Now if you do the right click on a folder->Mark all Mails as Read for a few folders one after the other, you will see the busy indicator near the folders. The messages will be eventually marked as read, but the busy indicator remains due to the above fetches. Curiously I let the machine running over night and it was still busy in the morning, with heavy disk activity from the maildir resource. The agent_config_akonadi_maildir_resource_0_changes.dat grew also big, it was 13MB. Furthermore even after I restarted the akonadi server and cleaned up the changes.dat file, the first access to a folder is very slow and the business is in the resource, not kmail. Further accesses are somewhat faster, even if I restart kmail.