[kdepim-users] Offline Email

[Michael Mol]

On Tuesday, June 21, 2016 07:30:18 PM Daniel Vrátil wrote:
> On Tuesday, June 21, 2016 1:17:37 PM CEST Michael Mol wrote:
> > # 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.

Agreed.

> 
> > 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....

Not really able to break anything, unless you count performance.

My frustration with having to edit my.cnf stems from the shift in context; my 
Akonadi data is now stored somewhere where the files aren't owned by my user 
account. (Unless there's some place under $HOME where there's a my.cnf file I 
didn't know about...)

> 
> 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...:-)

I wouldn't want that as a "first-run", but maybe as a "recommended value" user 
knobs would default to... ;)

The RAM consumption, especially, will vary greatly by user patterns, not just 
system memory available. One of my hats is as a DBA, and I'll attest that 
there's no silver bullet...

> > 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
-- 
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20160621/96fafe64/attachment.sig>