This is no duplicate of Bug 327017 - Message takes over 1 minute or 2 to show up due to Kmail syncing folders. as I checked in Akonadiconsole that there are no duplicate folders for Local Folders. This is with a clustered Exchange server. I also tested with Icedove 23.1 and there switching between mails in a folder is almost instant. Reproducible: Sometimes Steps to Reproduce: 1. Have large IMAP account (I think it doesn´t matter if its on Exchange or not, but I am not sure). 2. Access a folder with quite some mails (I tested with btrfs-ml which has about 13500 unread mails). 3. Switch between mails by clicking on them or with cursor keys. Actual Results: Displaying the mail takes 10-20 seconds during which "Receiving folder contents is displayed" (translated from german). Expected Results: The mail is displayed almost instantly (as long as the IMAP server does respond in time). It does so while there Akonadi does not synchronize folders here. I use the following workaround: Cause synchronizing through the huge lot of the mail folders takes quite long, I raised regular sync interval from 15 to 30 minutes. So at least during some time I have faster access times. I think I remember having read once that Akonadi is at some point single-threaded, i.e. can only do one task at a time. If this is the case I think it should at least pause any background tasks *immediately* on user input. Better yet, I think, is to support more than one task being processed at a time and supporting some kind of priority in scheduling them, so that background tasks can be set to lower priority. Currently this is a major issue in usability of KMail. I revert to Outlook Web Access or Icedove in case KMail is unresponsive, which with 15 minutes sync interval was quite often. I as a user just don´t like to wait for Akonadi getting to process my interactive request. Its not only with displaying mails, but also moving some or deleting some. With modifying operations it takes KMail even longer. Up to minutes. Also if KMail synchronizes a large folder it takes longer as well for it to respond even to requests to display a mail. Here this is with IMAP. I also see it on POP3 accounts with deleting mails directly after having told it to get receive new mails to me and sometimes also on other occastions. Maybe this just happens with really large mailboxes with lots of folders and up to tens of thousands of mails in some of them. For the IMAP account I already disabled subscription of linux-kernel-ml folder due to having more than 400000 unread mails in them. Still there is a MySQL database, and all Akonadi has to do is request the item I clicked on from the IMAP server. IMHO its not supposed to take that long and IMHO it has to do with internal scheduling in Akonadi. This is on a ThinkPad T520 with Sandybridge 2,5 GHz Dualcore and dual SSD BTRFS RAID 1. So the machine is really quite fast. The Exchange cluster is hosted within our ESX enviromnent and usually responds really fast in Outlook Web Access and Icedove. I think it has quite fast backing hardware as well. ms@merkaba:~> apt-show-versions | egrep "(kmail|akonadi)" akonadi-backend-mysql:all/sid 1.11.0-1 uptodate akonadi-backend-sqlite:amd64/sid 1.11.0-1 uptodate akonadi-server:amd64/sid 1.11.0-1 uptodate akonadiconsole:amd64/experimental 4:4.12.3-1 uptodate kmail:amd64/experimental 4:4.12.3-1 uptodate libakonadi-calendar4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-contact4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-dev:amd64/sid 1.11.0-1 uptodate libakonadi-kabc4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-kcal4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-kde4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-kmime4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-notes4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-socialutils4:amd64/experimental 4:4.12.3-1 uptodate libakonadi-xml4:amd64/experimental 4:4.12.3-1 uptodate libakonadiprotocolinternals1:amd64/sid 1.11.0-1 uptodate
Sometimes when Akonadi synchronizes folders KMail does not respond to any click on a mail to view it for *minutes*. It seems to be completely blocked out then.
Is this still the case with 4.13? I have several mailboxes with 17k+ mails (190k in total), and reading mails is even during synchronization near instant. I know there used to be problems, but for me they seem to be resolved.
I did not yet see KDE SC 4.13 packages for Debian. I will test with KDE SC 4.13 once packages become available. For now I raised innodb_buffer_pool_size considerably (from the default low 80 MiB to 1024 MiB), but KMail seems to be totally unresponsive here at the moment. Raising the buffer pool size on my laptop from 80 MiB to 256 MiB for a huge POP3 account seems to have helped, but here it does not seem to have any visible effect. Doesn't display a mail for over an hour already. With no significant activity – neither CPU or disk I/O wise – in atop and Akonadiconsole not showing any activity for the IMAP resource either. I am currently using Evolution with EWS plugin which gives much better results. Granted, it doesn't even try to synchronize folders I did not yet click on, but maybe thats a quite sane approach. (Seems to be choosable in configuration.)
(In reply to comment #3) > I did not yet see KDE SC 4.13 packages for Debian. I will test with KDE SC > 4.13 once packages become available. > > For now I raised innodb_buffer_pool_size considerably (from the default low > 80 MiB to 1024 MiB), but KMail seems to be totally unresponsive here at the > moment. Raising the buffer pool size on my laptop from 80 MiB to 256 MiB for > a huge POP3 account seems to have helped, but here it does not seem to have > any visible effect. Doesn't display a mail for over an hour already. With no > significant activity – neither CPU or disk I/O wise – in atop and > Akonadiconsole not showing any activity for the IMAP resource either. > > I am currently using Evolution with EWS plugin which gives much better > results. Granted, it doesn't even try to synchronize folders I did not yet > click on, but maybe thats a quite sane approach. (Seems to be choosable in > configuration.) FWIW, my innodb_buffer_pool_size is 8M and I have no such problems. If there is no cpu nor I/O activity I doubt it's doing anything. I never used pop, so no idea about that one, but maildir for local mail + imap for everything large works fine here. I can only suggest to check if the resource where you try to read mail is actually online and to check what akonadiserver returns using akonadiconsole. The protocol is very IMAP like, so you might be able to figure something out using the debugger in akonadiconsole.
If its not doing anything… true… I now restarted Akonadi and for a short time it seemed to be active, then it ran into bug #332013 but for *displaying* mails. Commenting there. I will recheck this with KDEPIM 4.13 once I can get it onto my Workstation as packages. Thanks, Martin
Okay, the slowness perceived also have to do with NFS on NetApp FAS. I now relocated ~/.local/share/akonadi to local Ext4 SoftRAID 1 on two 1,5 GB WD harddisks as explained in bug#332012. Its still not "perfect", but performance is way better than before. I am still using innodb_buffer_pool_size of 1GB for now, but I think I will review with with mysqltuner Perl-Skript. I do have the impression that raising this from 80 MB to 256 MB on my laptop for POP3 based accounts actually helped reduce MySQL disk I/O activity onto the dual BTRFS SSD setup there.
FWIW Nepomuk/Virtuoso is still running on NFS, as I never found any serious issues with that. It works nicely meanwhile. But it may contribute to performance issues and Nepomuk against local storage might be faster. Machine is connected with 1GBit ethernet and I consider latency to be quite low: ms@mango:~> ping netappfasnfsmachine PING netappfasnfsmachine (172.21.254.12) 56(84) bytes of data. 64 bytes from netappfasnfsmachine (172.21.254.12): icmp_seq=1 ttl=255 time=0.115 ms 64 bytes from netappfasnfsmachine (172.21.254.12): icmp_seq=2 ttl=255 time=0.179 ms 64 bytes from netappfasnfsmachine (172.21.254.12): icmp_seq=3 ttl=255 time=0.179 ms 64 bytes from netappfasnfsmachine (172.21.254.12): icmp_seq=4 ttl=255 time=0.201 ms 64 bytes from netappfasnfsmachine (172.21.254.12): icmp_seq=5 ttl=255 time=0.200 ms ^C --- netappfasnfsmachine ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.115/0.174/0.201/0.035 ms Anyway, waiting for KDE SC 4.13 packages to see how it performs with Baloo. I hope Baloo can run on NFS.
Bug 332624 - NFS support
Mail indexing is not enabled for the IMAP account at work, yet for the POP3 account it was. And now I found that the InnoDB buffer pool of 80 MiB size seems to be okay there and Akonadi maildir resource was 100% CPU busy while akonadi nepomuk feeder was feeding new mails to Nepomuk for indexing. I will disable the mail indexing on that POP3 setup as well and see what this gives. The index would not be that useful anyway, cause Baloo will recreate it then. I had it enabled, cause I really liked pressing Alt-F2, a part of the subject line, hit return and yada, there is this mail :)
Disabling mail indexing did not help with that. Maildir resource was still busy after that: Bug 332653 - After mail receive on filtering: Unable to retrieve item from resource: NO ImapParserException: Unable to read more data
Settings to resolved unmainted for now. I bet it will be better with current KDEPIM/Akonadi from git master.