[Kde-pim] Akonadi: single database design mistake?

[Dmitry Torokhov]

On Tue, Nov 29, 2011 at 10:28:17PM +0200, Andras Mantia wrote:
> Dmitry Torokhov wrote:
> 
> > On Tue, Nov 29, 2011 at 09:41:31PM +0200, Andras Mantia wrote:
> >> Anders Lund wrote:
> >> 
> >> > On Tirsdag den 29. november 2011, Milian Wolff wrote:
> >> >> I understand how this experience is far from optimal, but refrain from
> >> >> spreading such FUD as the above. I also have lots of problems with
> >> >> KMail2
> >> >> but  I actually sit down and try to fix them. Which so far works out
> >> >> pretty well.
> >> > 
> >> > Expressions of worries and frustration is not FUD.
> >> > 
> >> > Not everybody is a developer (though this list is for developers,
> >> > agreed), or wants to develop or debug kmail or akonadi. Does that make
> >> > us undesired as users? Does it mean we can not express our worries?
> >> 
> >> The problem is when users who are not developer draw the wrong conclusion
> >> why this is unusable. In the situation described here the problem is the
> >> conversion and nothing else.
> > 
> > If the problem was only with conversion then I kmail should be workign
> > reasonably now. 
> 
> The problem you see might have a lot of different reason then a design 
> mistake and the fact that akonadi uses a database server. It can be that the 
> migrator left uncommitted data in the change recorder that is still 
> processed by the server. It can be some broken state of the database. It can 
> be that you removed an account after failed migration and cleaning up the 
> database is written in a very inefficitent way on Akonadi side.
>  The problem is that you claimed the issue is because we use a database, 
> while there can be 10 other issues causing high CPU usage in the database 
> server. 

I am sorry, I shoudl have mentioned that this was done with branch new
akonadi database (as in rm -rf .local/share/akonadi) and re-creating my
accounts (I did not even want to mentioned how original import screwed up
my local folders that I use as archive for some emails). I also believe
that all tasks that mysqld was supposed to do are done becuase the
original email was written yestreday; it was stuk in moderation so I
subscribed to kde-pim list and re-sent.

> 
> > Alas I still see akonadi/mysql peg my CPU ifor a while
> > every time I switch mailboxes:
> > 
> >  1754 dtor      20   0 1175m  37m 4108 S 62.7  1.0  10:22.35 mysqld
> >  3375 dtor      20   0  909m 159m  22m R 61.4  4.0   8:21.99
> > akonadi_imap_re
> >  1751 dtor      20   0 1363m  20m 5016 S  6.9  0.5   8:59.32
> > akonadiserver
> 
> Well, for me mysqld hardly shows up in the top 10 or even more list of most 
> CPU intensive apps, and if it does for seconds, it is below 10%.

Would you mind staring sizes of your mailboxes and the rowcount on your
akonadi database? And what is your box? For the record I am reading my
mail from a Core2Duo laptop with 4Gb RAM and a mid-size SSD with TRIM
support. Up until now it was more than adequate (the real work is done
on headless workstations; mail is on dedicated servers).

> So I 
> suspect that it is busy with something the migrator or some other code asked 
> "in the past" in a bad way.

There is hardly any past as the database is branch new.

>  
> >> Yes, a valid concern for the user as he cannot get forward, but
> >> telling this is because of the database, or because of X is FUD if the
> >> claim is not carefully verified.
> > 
> > Dismissing that this is a FUD outright without considering my analysis
> > is not very constructive either.
> 
> Note that I dismiss your claim about the design mistake and not your 
> problem. I even gave tips how to solve or debug (the disk usage part).
> 
> Try what I wrote, a clean import and tell us your experience after.

Since it was a clean import I'd rather not repeat this excersize.

Thanks.

-- 
Dmitry
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/