pablo at blueoakdb.com
Wed Oct 12 15:02:29 BST 2016
[ 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....
>> 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
> 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.
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
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
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.
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph: 819.459.1926 iNum: 883.5100.0990.1054
More information about the kdepim-users