8:22 a.m.
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
--
Daniel Vrátil | dvratil(a)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