Re: Offline Email
Daniel Vrátil <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Organization | KDE |
| Message-ID | <3760575.H8tfjsNhWM@mjollnir> |
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 | [email protected] IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 _______________________________________________ KDE PIM users mailing list Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXaXmqAAoJEE1pVXrssTaDtzMQAMU0jwNDOZ2UC1+TlydiJy8E zajvYCsUOScNXb/Pr9MG+eDf0OnKOp6PwUBcoKCm/KbeLdcqDwh9Ff9ek03FBm4y O1HZWg5fyah5lumCKErl+99pOMUr7yZCZHdZe2qMskMW/Dy93SuWTu08koVbATnL esqvv80Kl4jqfqwgvY/v9D+jRoTxUAAhpswBIDbTg+TQmaUdm+kD+z+aG5p7Cuba YKrYYGfUDsOjWhyXiRfhB1M8RY6UmzA+PRNjKEfIgKG0VBIQYvS0psMeZW7RhGVT RHyk7vqWLw8uuMuk76m2HiwliKYwlpdzvXgrXK9WkV61VJtfyjIQEng6/z1TV0uA Fek9cjqUBNP9KeoKyqVdZD72PGO+Jts9K/dQzZAOeOwVBO/fZ/0Ri7h7sXuzMQDb fqXA1lD337MgZtpw49TZ1R5WtKkqNRM4chr8042rKN+xoQ00Y8owXI85iD1+BSpM 0wJjv0Dzelh3+kOeuTeuNM8e/BAvkMfEo16N1BnGCVav8MgX5Ev1ps00zUlD6b0/ EFC01ISMCbdqTK5nyYzSR2Jt8zzk2DLwsOG2mKi747hZet5HESK/RpzMpGWZStLc CjGsKyRUA+nJwN9BdQudt1Z+xjVaSUM71eMWAWO/x518Q8KlabiIM2k8ikHrCZbK +18tBytSjW1t9DD213kG =eRXm -----END PGP SIGNATURE-----