Problems with the last update to akonadi [Solved]

[Daniel Vrátil]

On Monday 14 of April 2014 06:02:49 Rex Dieter wrote:
> On 04/14/2014 05:56 AM, Laurent Rineau wrote:
> > Le Monday 14 April 2014 10:13:20 José Matos a écrit :
> >> On Thursday 10 April 2014 23:29:57 José Matos wrote:
> >>> Hi Daniel,
> >>> 
> >>>       the akonadi server seems to be trapped in a continuous loop. If I
> >>> 
> >>> kill one another one is started. So it is not obvious how to proceed.
> >>> 
> >>> Looking to top I notice that there is a mysqld process running for 55
> >>> min (the computer is now up for 7h24m).
> >>> 
> >>> This seems to be the same pattern of yesterday.
> >> 
> >> Just a followup, in case anyone has the same problem.
> >> 
> >> I have solved this last Thursday with Daniel's help.
> >> 
> >> The culprit was:
> >> 
> >> Sql error: The total number of locks exceeds the lock table size QMYSQL:
> >> Unable to execute query
> >> Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES
> >> PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> >> 
> >> and the solution was, since I am using an internal mysql server, was to
> >> increase the value of the innodb_buffer_pool_size parameter on
> >> ~/.local/share/akonadi/mysql.conf
> >> 
> >> The value that was there was of 8M and I have set it to 128M.
> > 
> > I was impacted by that bug too, but I did not found the correct fix. I
> > removed my Akonadi database last Friday.
> > 
> > I think that should be reported to upstream KDE, so that they find a way
> > to
> > smooth the upgrade.
> 

Hi,

> As a downstream/packaging issue, fedoras akonadi packaging currently
> opts to default to using the values in:
> /etc/akonadi/mysql-global-mobile.conf
> and not
> /etc/akonadi/mysql-global-big.conf
> (ie, compare each to /etc/aknoadi/mysql-global.conf)
> 
> The rationale being that the -big config, well, was *too* big,
> especially for casual users.  Perhaps we will have to rethink that.

Upstream doesn't think that 80MB innodb_buffer_pool_size is too big :-) and is 
in favor of using mysql-global.conf by default (as shown above, there's a 
reason for those values).  Upstream is actually not surprised that so many 
people complain about poor Akonadi performance, since they are all using what 
could be called a misconfigured database. innodb_buffer_pool_size is one of 
the most critical values for us that directly impact performance of queries 
and IO. I admit it's partly my fault for not noticing this when I took over 
the package, but it never occur to me someone would willingly used the 
crippled config :-)

Unless someone has a *real* reason not to do it, I'm going to switch to the 
-not-really-that-big config in our packages.

> In the meantime, yes, if the values in -mobile are problematic, then
> upstream should also consider adjusting things too.

The -mobile config assumes a device with limited HW resources, where so small 
innodb_buffer_pool_size actually makes sense. This is however not the case on 
desktop. 

With my Akonadi maintainer hat on, I think that we should actually remove this 
config now, since it's not tested at all and there's no real usecase for 
Akonadi on mobile device ATM. With my latest fixes to our fork of the SQLite 
driver, using SQLite backend should be much less pain and notably faster, so 
we can recommend mobile distributions to opt-in for SQLite.


Cheers,
Dan

> 
> 
> -- Rex
> _______________________________________________
> kde mailing list
> kde at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/kde
> New to KDE4? - get help from http://userbase.kde.org

-- 
Daniel Vrátil | dvratil at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/kde/attachments/20140415/3df60997/attachment.sig>