Problems with the last update to akonadi [Solved]
Ernesto Manríquez Mendoza
alejandronova at gmail.com
Tue Apr 15 15:09:05 UTC 2014
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 at 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?
More information about the kde
mailing list