El Mar 15 Abr 2014 15:22:42 Daniel Vrátil escribió:
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.
> >>> I
> >>> kill one another one is started. So it is not obvious how to
> >>> Looking to top I notice that there is a mysqld process running for
> >>> 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)
> >> PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> >> and the solution was, since I am using an internal mysql server,
> >> increase the value of the innodb_buffer_pool_size
> >> ~/.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
> > to
> > smooth the upgrade.
> As a downstream/packaging issue, fedoras akonadi packaging
> opts to default to using the values in:
> and not
> (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 :-)
is in favor of using mysql-global.conf by default (as shown above,
a reason for those values). Upstream is actually not surprised that
many people complain about poor Akonadi performance, since they are
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
for not noticing this when I took over the package, but it never
me someone would willingly used the crippled config :-)
Unless someone has a *real* reason not to do it, I'm going to switch to
-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
small innodb_buffer_pool_size actually makes sense. This is however
case on desktop.
With my Akonadi maintainer hat on, I think that we should actually
this config now, since it's not tested at all and there's no
for Akonadi on mobile device ATM. With my latest fixes to our fork of
SQLite driver, using SQLite backend should be much less pain and
faster, so we can recommend mobile distributions to opt-in for
> -- Rex
> kde mailing list
> New to KDE4? - get help from http://userbase.kde.org
My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is a
stream of crashes. Daniel, is it possible to make a mysql.conf file tailored