Akonadi dsaster

[Pablo Sanchez]

[ Comments below, in-line ]


On Wed, 12 Oct 2016 15:48:58 +0200, Martin Steigerwald wrote:
> Am Mittwoch, 12. Oktober 2016, 08:28:52 CEST schrieb Pablo Sanchez:
>> On Wed, 12 Oct 2016 13:59:37 +0200, O. Sinclair wrote:
>>> To me Martin makes the perfect point: a user should not have to fidget
>>> around in config files for database, .rc files, recreate accounts and so
>>> on. There is something inherently unstable in a setup that when doing an
>>> upgrade of system goes nearly unusable.
>>>
>>> I am still trying to avoid recreating my accounts and redownloading my
>>> email (I need offline access) but I can see it getting there day by day.
>>> And trying to find that way of getting Baloo to make distribution lists
>>> work again, preferably without having to recreate them. Again....
>>
>> Hi,
>>
>> MySQL/MariaDB/PG all make use of the O/S cache.  The only fiddling I
>> think would need tweaking is determining if disabling writing in fact
>> is fine.  The other proposed tunes I don't think make much
>> difference.
>
> AFAIK that is only true with MyISAM. InnoDB partly uses its own
> caching and while I have no measurement, raising the InnoDB buffer
> pool size has an effect that I claim I can perceive subjectively
> easily enough. It reduces latencies in KMail and and I think it also
> generates less I/O than with a lower value.

Hi Martin,

As a database engineer, I have to work objectively.  I generally use
'sar' data to measure O/S level metrics.  This is the definitive way
to determine whether a tune is working for us, neutral, or against us.

All DB's use caching.  What I am saying is that increasing the DB's
caching will not help in this single-user situation.  The reason why
is because the O/S' cache is being used.  This is good in one sense as
it minimizes having to tweak the DBMS for each and every user's
system.

The only thing that should make a difference would be whether to
ensure the DBMS' durability.  That's the fsync()'ing of the DB log.
Disabling it should improve performance at the cost of potential data
loss and/or corruption.


>> The biggest gain would still be to stop the KDE apps from sending many
>> queries per second.  If I recall correctly, it was upwards of 100+
>> queries per second.  There was no need for them.
>
> Sure thats very important. Dan/Milian did some work there, but its
> still too much as I read here in this thread.

That's right, the pressure must be reduced.

> Also the folder synchronization nonsense IMHO needs to stop.
> [ trimmed ]

A while back I offered my database services to help resolve the
problem.  Free.

But as I mentioned, I was told that since there was going to be a
major refactoring, only a stop-gap solution was to be put in place.

The relief you've seen on your CPU is a direct result (I believe! :)
of my feedback to Dan.

Cheers,
--
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph:    819.459.1926        iNum:  883.5100.0990.1054