[kdepim-users] Offline Email

Daniel Vrátil dvratil at kde.org
Tue Jun 21 18:30:18 BST 2016


On Tuesday, June 21, 2016 1:17:37 PM CEST Michael Mol wrote:
> There are a couple pieces of low-hanging fruit.
> 
> # Makes writes a little less robust. Fine for a desktop, not great for a
> # laptop. This is a dynamic variable, so if Akonadi *wanted* to, it could
> set # innodb_flush_log_at_trx_commit = 1 when the system gets low on
> battery, and # leave it at innodb_flush_log_at_trx_commit = 2 elsewhere,
> changing the # setting at runtime.
> innodb_flush_log_at_trx_commit = 2

Interesting! That indeed sounds like something that we could manage at runtime 
easilly.

> # Makes sure data that's likely to be 'hot' gets back into memory quickly.
> # This is the default in newer versions of MySQL.
> innodb_buffer_pool_load_at_startup=ON
> innodb_buffer_pool_dump_at_shutdown=ON
> 
> # Turn off InnoDB double buffering. InnoDB double-buffering is unnecessary
> on any # modern journaled filesystem that hasn't itself been tuned away
> from data # integrity. If the user has already done that, there is a an
> increased risk # of data loss in the event of a power failure.
> skip-innodb_doublewrite

User who tunes their filesystems like that are responsible for their own data 
losses, so I would not be very concerned with that.

> Other settings, like enablement and sizes of various caches, really ought to
> be exposed to the user somehow. :-|

Hmm, IMO if you are knowledgeable enough to be able to fine-tune the variables 
you probably have no problem manually editing them in my.conf. Once you 
introduce a UI with configuration like this people will start playing with the 
sliders and likely break something....

I have in my mind for some time now a sort of first run autodetection that 
would detect some basic characteristics (HDD vs SDD, how much RAM you have, 
...) and would adjust some of the cache numbers based on some predefined 
presets. Might be an interesting junior-job...:-)

Dan

> 
> On Tuesday, June 21, 2016 07:06:22 PM Daniel Vrátil wrote:
> > Indeed, massive amount of emails takes longer and requires bit more
> > resources. We can't unfortunately tune MySQL to cover all usecases (from
> > couple hundreds to hundreds of thousands) without one or the other side
> > complaining about performance issues or high resource consumption.
> > 
> > I have a rather good performance results with PostgreSQL btw without any
> > tuning btw.
> > 
> > For users with small amount of emails on only one or two accounts and
> > relatively low traffic I would recommend SQLite as they will not suffer
> > from concurrent-write issues.
> > 
> > Dan
> > 
> > On Tuesday, June 21, 2016 12:55:25 PM CEST Michael Mol wrote:
> > > I will note that will take a *long* time to synchronize if you have a
> > > great
> > > deal of email to synchronize, and it may require you to tune the MySQL
> > > instance Akonadi uses for system performance to be reasonable.
> > > 
> > > For example, on my system, I have these configured...it required me to
> > > point akonadi at a different mysqld than the one it wanted to spawn so I
> > > could get the configuration in place, but it works. (It's also tuned for
> > > my system, which has 16GB of RAM. If you have less, you'll want
> > > innodb_buffer_pool_size much lower.)
> > > 
> > > innodb_buffer_pool_size = 4096M
> > > innodb_buffer_pool_instances = 16
> > > innodb_flush_method=O_DIRECT
> > > innodb_buffer_pool_load_at_startup=ON
> > > innodb_buffer_pool_dump_at_shutdown=ON
> > > innodb_flush_log_at_trx_commit = 2
> > > innodb_file_per_table
> > > 
> > > skip-innodb_doublewrite
> > > query_cache_type=ON
> > > query_cache_size=256M
> > > thread_cache_size=256
> > > 
> > > I also have a couple sysctl values set:
> > > 
> > > vm.dirty_background_bytes = 131072
> > > vm.dirty_bytes = 1048576
> > > 
> > > 
> > > With those, I can heavy disk activity coming from MySQL during the
> > > initial
> > > sync process (ten years of email, in my case), with the rest of the
> > > system
> > > remaining somewhat usable. Once the initial sync is complete, system
> > > load
> > > dies down considerably. Though a full resync of a folder with hundreds
> > > of
> > > thousands of messages in it will still take quite a while, it won't make
> > > the rest of the computer unusable.
> > > 
> > > On Tuesday, June 21, 2016 06:47:00 PM Daniel Vrátil wrote:
> > > > On Tuesday, June 21, 2016 9:39:29 AM CEST Mike Cleveland wrote:
> > > > > Greetings,
> > > > > 
> > > > > 
> > > > > 
> > > > > I'm wondering if Kontact email can be used offline acceptably. As in
> > > > > writing and responding to emails offline and then automatically
> > > > > sending
> > > > > when online.
> > > > 
> > > > Hi Mike,
> > > > 
> > > > being able to work with your emails while not connected to internet is
> > > > one
> > > > of the core features of Kontact.
> > > > 
> > > > When setting up you IMAP account you can check "Download all messages
> > > > for
> > > > offline use" and you will have all your emails cached locally. You can
> > > > do
> > > > anything you want to with them like if you were online and Kontact
> > > > will
> > > > automatically replay all the changes once you connect to internet
> > > > again.
> > > > 
> > > > Cheers,
> > > > Daniel
> > > > 
> > > > > I just heard about Open365 today and am getting started, sorry for
> > > > > the
> > > > > newbie question.
> > > > > 
> > > > > 
> > > > > 
> > > > > Sincerely,
> > > > > 
> > > > > 
> > > > > 
> > > > > Mike


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20160621/a9a642cf/attachment.sig>


More information about the kdepim-users mailing list