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

[Milian Wolff]

On Tuesday 29 November 2011 12:10:30 Dmitry Torokhov wrote:
> On Tue, Nov 29, 2011 at 08:05:02PM +0100, Milian Wolff wrote:
> > On Tuesday 29 November 2011 09:46:14 Dmitry Torokhov wrote:
> > > Hi,
> > > 
> > > So I have upgraded from very usable setup with Fedota 15/KDE 4.6.x to
> > > Fedora 16 with shiny new KDE 4.7.3 and brand new KDE PIM suite and as
> > > many users found that the new version Akonadi/Kmail2 is pretty much
> > > unusable. The conversion of my archive mailbox (mixed maildir) and 2
> > > IMAP accounts ran for over 8 hours and I am not quite sure what state it
> > > is in the moment as Kontact is trying to open my work mailbox for over
> > > 10 minutes now (ever since I got to my desk and woke up my laptop).
> > > 
> > > Looking at the Akonadi mysql database I see that I have 3 large tables:
> > > - parttable:			587230 rows;
> > > - pimitemflagrelation:		241688 rows;
> > > - pimitemtable:			294840 rows;
> > 
> > I just want to comment on this and leave the rest to the real pimpsters:
> > 
> > You say here that this is an outrageous amount of data and that it has to
> > be slow and what not. That is actually not true. This are just a couple
> > of thousand rows,
> 
> As I shown above, not a couple thoushands but couple _hundred_
> thousands. Please test with real setups.

I do, and I have been working with MySQL in the past quite a lot. If you set 
proper indizes and write good queries, it handles that workload just fine. Lots 
of big websites out there use it.

> > something that MySQL should handle just fine.
> > 
> > Note that the KDEPim stack is continously being optimized and I severly
> > doubt that the KDE 4.7 version is even near the place where MySQL was the
> > bottleneck.
> 
> Again, I have shown that mysqld on my box took about 8 hours to process
> my accounts, so for me it was the bottleneck as my laptop was unusable
> for that long (and hardly usable now).

If I run top on my laptop, I see that X, skype, firefox alls have "time" above 
10 hours. So what? My system runs smoothely and I doubt that these numbers say 
anything on performance.

And let me try to make it clear again: I don't doubt that KMail2 is slow and 
must be optimized. I simply doubt that KMail2 is slow *because of* MySQL. 
Quite possibly KMail2/Akonadi does some unoptimized queries, or too many of 
those. Still, that is not an issue of MySQL, but one of kmail/akonadi.

> > 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.
> This is not FUD, this is my analysis and invitation to discuss the
> issues many users are facing.
> 
> > Another thing: If we ever come to the point where MySQL is the bottleneck,
> > the current architecture should make it rather simple to come up with an
> > alternative, optimized architecture. Personally, I just doubt that we are
> > able to design a relational database from scratch that will outperform
> > MySQL so easily...
> 
> Thet is the main question: do we really want a monolithic database here.

Again: why not? Show me actual profiling data that justifies your statement. Run 
KMail through vtune, callgrind, perf, pace, ... and proof that KMail is slow 
because MySQL is the bottleneck.

Before this is not done, this discussion is just hot air.

> > Bye
> > 
> > PS: If you want to help KDEPim constructively, build it from master (it is
> > much better there already compared to the 4.7 version) and profile it.
> > Show us data from callgrind, perf, systemtap, vtune, ... That way we can
> > actually improve it and don't have to waste time in a debate on
> > principles.
> No, I do not think I am wasting time here, sorry you have this
> impression.

see above
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111129/26f1e042/attachment.sig>
-------------- next part --------------
_______________________________________________
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/