https://bugs.kde.org/show_bug.cgi?id=322083
Bug ID: 322083
Summary: CollectionSync always start a database transaction,
even when no update needs to be done
Classification: Unclassified
Product: Akonadi
Version: unspecified
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kdepim-bugs@kde.org
Reporter: alexpigna@gmail.com
Disclaimer: I'm not expert in akonadi codebase, so the terminology might not be
100% correct.
CollectionSync derives from TransactionSequence, which means that all the Jobs
added are wrapped in a database transaction. This probably make sense to
guarantee correctness in case of concurrent updates.
The problem is that a transaction is started even in the case when no updates
needs to be made. The effect of this is that mysql (when it is the backend) is
no longer able to optimize the load of the local collection data and needs to
write book-keeping data on the log. This means that in the very frequent case
of no updates needed (so, theoretically read only operation) mysqld will still
be writing to disk, with an effect on system performance and battery usage.
I'm not sure what could be a good solution to this problem, my guess is that it
could make sense to operate in two phases:
1) Load the local collection without starting a transaction and compare with
the remote one to see if anything needs to be updated
2) If needed, start a transaction and do the complete sync. This will cause
overhead when updates are needed, but hopefully this is balanced by the
optimization of the read only case.
I think another possible solution would be to use explicit table locks, but
akonadi currently seems to have no concept of locking.
Reproducible: Always
Steps to Reproduce:
1. Add an IMAP resource that is polled regularly
2. Watch akonadi mysqld process with strace, grep for 'pwrite'
Actual Results:
I can see write operations happening when apparently no new mails are arriving
Expected Results:
Read only operations should be read-only
--
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs
