From kde-pim Thu Mar 27 11:24:39 2014 From: Daniel =?ISO-8859-1?Q?Vr=E1til?= Date: Thu, 27 Mar 2014 11:24:39 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi MySQL backend: tuning for larger accounts or switching to MariaDB with a diffe Message-Id: <4614445.Yhb14Ejxku () odin> X-MARC-Message: https://marc.info/?l=kde-pim&m=139591950407137 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7260032108114319325==" --===============7260032108114319325== Content-Type: multipart/signed; boundary="nextPart1886212.YvUS9WCBC4"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1886212.YvUS9WCBC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Wednesday 26 of March 2014 22:12:53 Martin Steigerwald wrote: > Am Mittwoch, 26. M=E4rz 2014, 21:22:33 schrieb Martin Steigerwald: > > Am Mittwoch, 26. M=E4rz 2014, 20:22:28 schrieb Martin Steigerwald: > > > > > InnoDB is difficult as innodb_buffer_pool_size needs to take = free > > > > > memory > > > > > into account which can change quite rapidly on desktops or an= ything > > > > > else > > > > > than a dedicated database server. A engine which uses Linux > > > > > pagecache > > > > > for > > > > > most of its caching would be interesting I think. > > > >=20 > > > > Maybe we could have some kind of "initial setup" tool that woul= d check > > > > available memory and would update innodb_buffer_pool_size depen= ding on > > > > that > > > > (taking in account some max limit, min limit, max percentage, .= ..) > > >=20 > > > Well I am backing off a bit at the moment. Maybe those read burst= s I > > > observed where not related to InnoDB buffer pool size, but to so= mething > > > else. If I see it again, I try to look in Akonadiconsole as to wh= at > > > Akonadi > > > is doing there. > >=20 > > There is indeed some stuff in Akonadiconsole there. > >=20 > > And now I had this long wait for KMail to do anything again. After > > downloading / filtering new mail. > >=20 > > According to Akonadiconsole akonadi nepomuk feeder was indexing and= > > according to atop akonadi maildir resource was hogging one Sandybri= dge > > core > > for 100% for minutes. > >=20 > > Akonadiconsole Query Debugger showed queries to get payload bodies,= also > > from that kernel-ml folder. And I have quite some wait times in Job= > > Tracker > > now, for Akonadi::ItemFetchJob. I have wait times up to: > >=20 > > 00:05:33.069 > >=20 > > Five of those wait times between 5 and 6 minutes. > >=20 > > Four between 2-3 minutes. > >=20 > > Five between 10-20 seconds. > >=20 > > Why this time is so long, I don=B4t know. > >=20 > >=20 > > Akonadi seems to block out KMail due to this mail indexing backgrou= nd > > activity, which I reported already: > >=20 > > Bug 331848 - displaying, moving, deleting mails takes 10-20 seconds= when > > Akonadi synchronizes in background > >=20 > > https://bugs.kde.org/show_bug.cgi?id=3D331848 > >=20 > > But at work I do not have mail indexing enabled so far, yet this wa= s on > > NFS > > still as I reported the bug. > >=20 > >=20 > > I think I just disable mail indexing for now for this POP3 setup, u= ntil I > > can install KDE SC 4.13 including new KDEPIM and Baloo. > >=20 > > Well, I learned about debugging performance issues with Akonadi. > >=20 > >=20 > > I am inclined to close my MySQL tuning related report. I do not hav= e the > > impression anymore that it is very important at the moment. What do= you > > think? > >=20 > > So finishing analysis for now. >=20 > I got miss rates now: >=20 >=20 > BUFFER POOL AND MEMORY > ---------------------- > Total memory allocated 85852160; in additional pool allocated 0 > Dictionary memory allocated 103892 > Buffer pool size 5120 > Free buffers 0 > Database pages 4871 > Old database pages 1778 > Modified db pages 0 > Pending reads 0 > Pending writes: LRU 0, flush list 0, single page 0 > Pages made young 659333, not young 0 > 3302.78 youngs/s, 0.00 non-youngs/s > Pages read 619033, created 84, written 1204 > 3191.25 reads/s, 0.53 creates/s, 10.80 writes/s > Buffer pool hit rate 977 / 1000, young-making rate 24 / 1000 not 0 / = 1000 > Pages read ahead 79.79/s, evicted without access 21.00/s, Random read= ahead > 0.00/s > LRU len: 4871, unzip_LRU len: 0 > I/O sum[267946]:cur[0], unzip sum[0]:cur[0] >=20 >=20 > Another example: > ---------------------- > BUFFER POOL AND MEMORY > ---------------------- > Total memory allocated 85852160; in additional pool allocated 0 > Dictionary memory allocated 103892 > Buffer pool size 5120 > Free buffers 0 > Database pages 4942 > Old database pages 1804 > Modified db pages 10 > Pending reads 0 > Pending writes: LRU 0, flush list 0, single page 0 > Pages made young 1076283, not young 0 > 10570.21 youngs/s, 0.00 non-youngs/s > Pages read 1015530, created 110, written 1673 > 10471.76 reads/s, 0.50 creates/s, 10.00 writes/s > Buffer pool hit rate 965 / 1000, young-making rate 36 / 1000 not 0 / = 1000 > Pages read ahead 479.76/s, evicted without access 78.46/s, Random rea= d ahead > 0.00/s > LRU len: 4942, unzip_LRU len: 0 > I/O sum[88144]:cur[7656], unzip sum[0]:cur[0] >=20 > see: >=20 > Bug 332626 - MySQL tuning: adaption of MySQL tuning options for large= r > accounts > https://bugs.kde.org/show_bug.cgi?id=3D332626#c5 >=20 >=20 > And I got: >=20 > Bug 332653 - After mail receive on filtering: Unable to retrieve item= from > resource: NO ImapParserException: Unable to read more data >=20 >=20 > This should have been with disabled mail indexing. I will observe fur= ther > and really close analysis for now. Need to get a clear head again, be= fore > continuing. >=20 > Ciao, Hi, thanks a lot for all the analysis. I will need to read up on this and c= onsult=20 MySQL documentation first, so I'll go through it next week :-) Dan =2D-=20 Daniel Vr=E1til | dvratil@redhat.com | dvratil on #kde-devel, #kontact,= #akonadi KDE Desktop Team Associate Software Engineer, Red Hat, Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 --nextPart1886212.YvUS9WCBC4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJTNAp3AAoJEMWdYU9vSuNI1wAIAKsH6pQ6W809ANccdkHHrXBO KjbFQw57RPBIsahSRaKaWR/kjcXmW3qsk1cq3nuwHRtj1+W+DXC+BvaQdg6cvNwR sA25QLkKQHD6FiXOqTWwY/3eq2K3wNDdlf53XgKpZNt/e277qKzlwhQDnROTOzE9 FAkyvdnLNW+dKV1cWRGgGT4ouo2uvoMEIEUebGgPe2ldHhMC9vzTHK6JbYpwLF2a V2le8wSjyR8/zuVF8PF8z0hDV1qpuHfbLIOYfQ5WSc5WNDxDv0UDE51mp8PJPbFh aJe0e8ofi1JwTI7KUyQNh1odW2Aosd9eLRfMIlSkj6p4C0PJCJw0XRcqeu1qv+s= =MeZI -----END PGP SIGNATURE----- --nextPart1886212.YvUS9WCBC4-- --===============7260032108114319325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE PIM mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ --===============7260032108114319325==--