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.
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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/kde
> 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
for Akonadi?