Re: Since update slowdown Kontact
Hi Martin,
Thank you, for your answer, I see that you have identified the problem much
better than I have, however I have confidence in the Kde team to correct this
Bug.
Should I report a bug? if so, to implicate Akonadi or Kmail?
Philippe Merlin
Le vendredi 29 mai 2020, 16:15:40 CEST Martin Steigerwald a écrit :
> Hi Merlin.
>
> MERLIN Philippe - 29.05.20, 14:57:26 CEST:
> > Since update Kontact 5.14.1 (20.04.0) , since the update the access
> > and reading of the received messages is often very slow a message
> > appears "Reception of the content of the message please wait" Same
> > problem for the trashing of messages.
> > Do you have the same problem?
>
> I do have this issue with KMail while Akonadi synchronizes a maildir
> folder.
>
> Even for little folders this appears to take much longer than before. 100%
> of CPU usage (well… not quite exactly but read on) on one CPUs for minutes
> for a folder with just 33000 messages.
>
> If I read the numbers atop is telling me in
>
> CPU | sys 4% | user 111% | irq 0% | idle 285% | wait
> 0% | guest 0% | ipc 0.08 | cycl 911MHz | curf 2.98GHz | curscal
> 92% | cpu | sys 0% | user 100% | irq 0% | idle 0% |
> cpu003 w 0% | guest 0% | ipc 0.02 | cycl 3.10GHz | curf 2.94GHz
> | curscal 91% |
>
> correctly (see manpage about ipc and cycl there), then that is mostly the
> CPU being stalled while accessing memory. I straced it and it *polled* a
> lot on some file descriptor. As far as I remember it was this one:
> "6 -> 'anon_inode:[eventfd]'".
>
> Interestingly enough, if I stop the "akonadi_maildir_resource" process by
> sending it SIGTERM, then KMail almost instantly responds again.
>
> This points back to the one issue in Akonadi that after all the time is
> still not fixed: It can only do one thing at a time. You read that right:
> It can only do one thing at a time. That means: Long term tasks block out
> short term tasks like "I like to read this mail", which in my point of view
> is an absolute no-go for anything with a user interface. Added to that is
> that I believe it *needlessly* synchronizes the same folders over and over
> and over again. I'd like to tell it: Akonadi, see, its all your mail
> folders, I don't mess with them – well usually that is – so if you put a
> mail there, it will be there tomorrow, and the day after and the day after…
> so as long as you do not get your state wrong, there is virtually never
> *ever* a need to synchronize a folder, once you have done it and keep it up
> to date from then on. See, even this BTRFS RAID 1 filesystem that stores
> the maildir does not loose any files nowadays anymore – actually it never
> really did, but it has some issues that are fixed by now. But *can't*. It
> decides to do whatever background tasks it likes to… *blocking* me from
> reading my mail. The right priority is this: If I click a mail, get that
> mail to me. *Now*. Anything else is much less important. I think once it
> gets that basic thing right, users will be much, much, much happier with
> it.
>
> Also the stalls during message filtering after POP3 retrieval also appeared
> again…
>
> To be honest: I am disappointed about that. I know its only a few people
> working on Akonadi and KDEPIM. I don't blame anyone. I get the idea behind
> the concept, but I wonder whether the current thing really can be fixed
> within a somewhat sensible amount of time. I know there was or is a grand
> plan to fix it all up. Dan and others did quite some steps to do so, but it
> is not yet completed. I even defended Akonadi quite some times… however
> after all these years some of these basic things are still not fixed.
>
> I switched to Evolution for work due to Office 365 EWS support working way
> better there. It has it own shortcomings, but I tell you what: This thing
> *just* works. And I had no need to do deal with any of the complexities
> that often enough showed up with Akonadi. The thing *just works*. As a PIM
> application suite should do. Basically I think I just did not switch
> privately yet, cause I would have quite some data, accounts and things to
> migrate and configure again. That is easier at work.
>
> I know… do it yourself. However I feel I would not be able to without
> investing quite some time to dig out and improve my C/C++ skills *and*
> actually really understanding Akonadi's internal working. I may have a
> deeper understanding than many users, but… if it would be about fixing
> those issues… or even just diagnosing the stalls during message filter
> after POP3 retrieval… I don't even have a clue where exactly to start.
>
> I really consider looking into Kube and Sync… but that does not do POP3
> and does not offer any other way to archive old mails locally instead of
> having years of mail history sitting on the server.
>
> It really is a pity, cause these KDEPIM applications are really, really nice
> otherwise!
>
> I know this in part has been a rant… but I felt like getting that out and I
> tried to be fair to everyone nonetheless. And I know: Unless I fix it
> myself, I can only hope that someone at some point takes the time to fix
> it. I am not in a position to demand that anyone fixes it for me (well and
> maybe them to) in their spare time.
>
> Best,
Reply to: