--===============7823261819061068804==
Content-Type: multipart/signed; boundary="nextPart4394432.pIv4sVD9ya"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart4394432.pIv4sVD9ya
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Thursday, December 18, 2014 01:03:42 PM Martin Steigerwald wrote:
> Hello!
>=20
> I have been testing c733429f4fa9696fb027ddc946e54f6bbb68deaf from 1.1=
3
> branch of Akonadi and just as a short heads up:
>=20
> It works nicely.
>=20
> I see lot less load on MySQL.
>=20
> By magnitudes.
>=20
> So thats great!
>=20
> Thank you.
>=20
>=20
> Yet it doesn=C2=B4t solve some other existing issues with current Ako=
nadi:
>=20
> What I still see at a time is that Akonadi doesn=C2=B4t respond to KM=
ail in a
> timely manner, up to the point that KMail even looses the connection =
to
> Akonadi and then both sit there doing nothing anymore unless I restar=
t
> KMail. I would like to easily see what Akonadi is doing at that time.=
 Maybe
> you have some ideas on how I can see it.

KMail cannot really lose connection to Akonadi. Most likely the session=
 get's=20
blocked on a DBus call, which times out, leaving a dangling task in=20
ResourceScheduler.


> I see akonadi maildir resource with high load then, sometimes MySQL a=
t
> around 100-150%, but more often just maildir resource and akonadiserv=
er. It
> may be synchronizing folders at that time, I sometimes don=C2=B4t kno=
w exactly,
> cause often Akonadiconsole doesn=C2=B4t provide any useful feedback o=
n what the
> resource is doing at the moment. Sometimes I see its synchronizing a
> folder, sometimes I see no info in Akonadiconsole while it still hogs=
 a CPU
> core for a while.

The problem with maildir is that we don't hold it stored in Akonadi for=
 very=20
long - the data are loaded on demand from maildir into Akonadi and drop=
ped=20
soon after to reduce disk usage (the file is already once locally in th=
e=20
maildir, no reason to keep it duplicated in Akonadi). This works reason=
ably=20
for reasonably-sized maildirs, but of course fails utterly on massive=20=

maildirs. I don't see how this could be solved easily, other than disab=
ling=20
the cache expiration for maildir folders.


> I remember that I optimized the maildir scan by stopping it from sort=
ing the
> maildir when trying to list it. Yet I still wonder why on earth it
> synchronizes at all:  And in what circumstances. If Akonadi stored th=
e
> files there, they will be there tomorrow as well =E2=80=93 thats the =
whole purpose
> a filesystem is about. So during runtime of Akonadi it has inotify on=
 them
> should another app add a mail there, so there is no business to *ever=
*
> synchronize a maildir at all during runtime of Akonadi, except on the=
 first
> time a folder is accessed after startup of Akonadi where it may check=

> whether an app dropped a mail there while Akonadi was stopped.
>=20
> I hope in the next time I have some more time to actually at least tr=
y to
> diagnose the KMail Akonadi connection breakup. Its the most annoying =
thing
> for me currently as it happens one or two times a day at least usuall=
y.
>=20
> So thats important points for Akonadi Next IMHO:
>=20
> 1) Provide good progress report on what each resource is doing. A use=
r who
> sees a process hogging a CPU core without *any* feedback as to *why* =
will
> likely get dissatisfied with it. Of course, if that kind of thing doe=
sn=C2=B4t
> happen with Akonadi Next anymore, this point could be skipped. Or pro=
gress
> report made less often in order to not harm the performance by progre=
ss
> reporting.

Akonadi does not see into resources, it's up to resources to report wha=
t they=20
are doing. And often "less is more" in this case. It's better to just s=
ay=20
"Synchronizing emails" instead of having tons of random status messages=
 that=20
don't really say anything useful. Having descriptive status messages is=
 not a=20
solution for the problem at hand. The solution is to fix the resources =
not to=20
hog cpu at 100% for hours.


> 2) Do only work that is *necessary*. Be as lazy as you can get. As I
> suspected for a long time and as recent optimization work has shown:
> Current Akonadi did a lot of work that wasn=C2=B4t necessary. And I t=
hink in
> case of folder synchronization it still does useless work.
>=20
> Ciao,

=2D-=20
Daniel Vr=C3=A1til | dvratil@redhat.com | dvratil on #kde-devel, #konta=
ct, #akonadi
Software Engineer - KDE Desktop Team, Red Hat Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
--nextPart4394432.pIv4sVD9ya
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

iQEcBAABAgAGBQJUktxRAAoJEMWdYU9vSuNINNEH/3JIzfsg1P7UMZ0y8NOvmPKL
YZFmkiAyw6P7PTYak/i+i8RPBzACk25tLo/JEegNhGOB4RMbamz6Bc4tj+5CepOU
/WpApsDzCppvh3fEwJJUOlNKvKd9c4sf67EToUgOkVNTc9nyJ9UizGHPpCOyWN8m
df1SR2ynBJ1toqyXNqUANRD7htVG4aqXx4uX8Wt9HCE3D42FKdPk03jLB8+KYPR2
oyQ8++jtzcI71lQiR0SCV78T8yS1peURrCfVxjM8YQsGVZCejq4Utk0VvJ/E8+kd
2XcwvULZ6jkPItqi0UD9T+i2ner3Oksi/ngrJnXtBJGpJgJQJyQ9KW9ttvJTfoc=
=CVSk
-----END PGP SIGNATURE-----

--nextPart4394432.pIv4sVD9ya--


--===============7823261819061068804==
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/
--===============7823261819061068804==--