| Summary: | displaying, moving, deleting mails takes 10-20 seconds when Akonadi synchronizes in background | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Martin Steigerwald <martin.steigerwald> |
| Component: | message list | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | dvratil, Martin, mollekopf |
| Priority: | NOR | ||
| Version: | 4.12.2 | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Bug Depends on: | |||
| Bug Blocks: | 332624 | ||
|
Description
Martin Steigerwald
2014-03-07 11:29:06 UTC
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. |