| Summary: | extremely slow IMAP performance, displaying mails takes minutes | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Gunter Ohrner <kdebugs> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | axel.braun, bugs-kde, dvratil, mah, mailinglist, mindboosternoori, Mr.Gosh, nortexoid, oliver.jusinger |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
*** Bug 186108 has been marked as a duplicate of this bug. *** *** Bug 183752 has been marked as a duplicate of this bug. *** This could be a duplicate of bug 181117 I just found out that my probelm is / was related to virutal search folders. And before you shout at me: No, none was visible, otherwise I'd have had this idea much earlier. The "Search Folders" node in the folders tree was empty. However, there was a file in ~/.kde4/share/apps/kmail/search which contained information about the last or one of the last seaches I did. After I deleted this file, the performance problem was gone. So, there actually seem to be 2 bugs: 1) Why did kmail perform a search on every startup of which the results were never displayed? 2) If a search has the impact on kMail which I observed, automatic search folders are more a non-feature than a feature... :-/ Actually, there's even a bug 3 I just remembered: 3) kMail was *very* crashy while this invisible / hidden background search was running, if I tried to use it in this state, I frequently got SIGSEVs if it even reacted... Greetings, Gunter Looks I'm running into the same problem with 1.12.1 (KDE 4.3.1) after the WLAN connection dropped during mail fetch. I already deleted all temporary folder, caches etc, but the problem persists: At start of KMail, some minutes 100% CPU load and Kmail more or less frozen. Thereafter mail fetching etc is OK. Any idea how one can trace the problem at startup? Did you already try to delete the file I mentioned in comment #4? (In reply to comment #6) > Did you already try to delete the file I mentioned in comment #4? Indeed, that helped. Looks like that search thing is really the non-feature. Thanks for your hint! Ax As this really happens *regulary* after every search, I feel it is critical. can one change the priority accordingly? And BTW, it is not specific to Debian, my problem is on SuSE Same problem for me - after ever start of kmail the system got unresponsive for 15-20min with *lots* of disc activity going on. This was caused mainly through my IMAP folder with 9000+ messages, all others where to small to see this impact. Kmail did a search on every startup without showing its results or being requested to do so... Deleting the files mentioned in comment #4 fixed this problem. KMail 1.12.2 on debian unstable (kmail 4:4.3.2-1) Seen this problem too, deleting the files in ./search seams to help. But noted that the files with empty base parameter was "last Search" and "TO dos", there was an entry in native language "sidste søgning" (containing danish letter) After deleting all files restarting kmail and making a search only the danish version of the files came back and the system is _not_ slow now. Could this be an upgrade cleanup / language mix error. This bug still seems to exist in debian squeeze kmail 4:4.4.11.1+l10n-1. Here the last search (by dialog) ist stored in ".kde/share/apps/kmail/search/Letzte Suche" (filename language dependend) and some few times it does not get deleted on the next start of kmail, but instead is searched (which is anoying on big imap folders). However I can not reproduce the problem. When it happenened, there were no other files (like *.index.*) in the search-Folder. I killed and restarted kmail several times, the file never got deleted, I had to remove it by myself. The searchfile originated from a search in an imap subfolder, but it seemed to me that in that bug-case after the start all my imap folders and accounts where checked (filter protocol), unfortunately i can't tell for sure and I don't have the content of the search file. Also happening to me, thanks to the bug reporter who found out the "remove 'Last Search'" solution! Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback. Kmail2 can still be pretty slow at showing emails, especially ones just downloaded, at least if "Download all messages for offline use" is UNchecked. This is version 4.81 beta 1. (In reply to Michael D from comment #14) > Kmail2 can still be pretty slow at showing emails, especially ones just > downloaded, at least if "Download all messages for offline use" is > UNchecked. This is version 4.81 beta 1. *This* bug specfically concerns slowdows caused by remembered searches and can be worked around as described above if it happens. kMail / Akonadi currently does have other severe performance issues, though, which can cause delays up to several minutes simply after switching folders until kMail is fully usable again. See the following bugs for example, maybe the behaviour you're experiencing is somehow related to one of those: https://bugs.kde.org/show_bug.cgi?id=338571 https://bugs.kde.org/show_bug.cgi?id=352604 Cionsidering the age of bug 338571 my hope's not too high that it might be fixed anytime soon, though... (In reply to Gunter Ohrner from comment #15) > (In reply to Michael D from comment #14) > > Kmail2 can still be pretty slow at showing emails, especially ones just > > downloaded, at least if "Download all messages for offline use" is > > UNchecked. This is version 4.81 beta 1. > > *This* bug specfically concerns slowdows caused by remembered searches and > can be worked around as described above if it happens. > > kMail / Akonadi currently does have other severe performance issues, though, > which can cause delays up to several minutes simply after switching folders > until kMail is fully usable again. See the following bugs for example, maybe > the behaviour you're experiencing is somehow related to one of those: > > https://bugs.kde.org/show_bug.cgi?id=338571 > https://bugs.kde.org/show_bug.cgi?id=352604 > > Cionsidering the age of bug 338571 my hope's not too high that it might be > fixed anytime soon, though... Thanks for the bug links. I've enabled "Download all messages for offline use" on all my computers now because the performance difference is night and day. What isn't clear is whether that means it will download messages from every subscribed imap folder (including my huge "All Mail" folders in gmail), or just the inbox. Does anyone know? > What isn't clear is whether that means it will download messages from every subscribed
> imap folder (including my huge "All Mail" folders in gmail), or just the inbox. Does anyone know?
Yes, it means all your emails from all your folders for that particular account are cached locally. If you don't want your 'All Mail' folder to be cached locally, you can either unsubscribe - i.e. completely hide the folder from KMail (right-click the folder in KMail -> Manage Local Subscription) , or you can change the folder cache policy - i.e. not cache emails for that particular folder (right-click the folder in KMail -> Folder properties -> Retrieval -> uncheck "Use options from parent folder or account", check "Retrieve message bodies on demand").
|
Version: (using KDE 4.2.0) OS: Linux Installed from: Debian testing/unstable Packages kMail since KDE 4.2.0 takes ages until it's able to display mails and one can navigate those mails. I did not experience anything similar with KDE up to 4.2RC2. In my setup, kMail accesses a local Dovecot IMAP server, the mail account has about 100 to 200 maildir folders with different amounts of mails in each. After starting, kMail displays the last selected mail nearly immediately and then starts to "do something". During this period, kMail's UI is not completely frozen, but extremely sluggish. The "busy" indicator in main window's lower right corner will jump back and forth, kMail eats 100% CPU and you cannot view any mails. Selecting a new folder will result in the message "Abholen des Ordnerinhalts, bitte warten..." ("Fetching folder contents, please wait...") This state takes up to several minutes, after which kMail will become responsive again. This also seems to happen only once after starting Kmail, though I'm not sure if it might also happen after fetching mails into my local IMAP mail spool. As already mentioned, this problem is relatively new, I'm pretty sure it did not happen up to KDE 4.2RC2 (I would have noticed quickly if id had ;) and it also does not happen if I use other IMAP clients to access the same local mail account. Also it's kMail eating the CPU, not the local dovecot server. I hope someone has any idea what may be wrong with either kMail or my setup...