[Kde-pim] Akonadi MySQL backend: Using a file per table in order to be able to free disk space on truncating?

[Volker Krause]

Hi,

On Friday 10 August 2012 12:39:34 Martin Steigerwald wrote:
> On doing some research regarding MySQL performance tuning I have been
> given the hint to consider using a file per table via
> "innodb_file_per_table" option.
> 
> Mainly cause of this advantage:
> | · Reclaiming disk space when truncating a table."
> 
> http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html
> 
> And this user comment:
> | Posted by Chris Wagner on June 2 2011 11:23pm
> | 
> | It is absurd that there is not a builtin function to compact the ibdata
> | file to reclaim unused space to the OS. *ALWAYS* use
> | innodb_file_per_table.
> 
> http://dev.mysql.com/doc/refman/5.5/en/innodb-data-log-reconfiguration.html
> 
> 
> Last I checked – I am currently using PostgreSQL plugin where such a
> vacuuming is always possible AFAIK – the mysql.conf for Akonadi started
> MySQL didn´t include this.

Are you sure? server/src/storage/mysql-global.conf (which is the template used 
for the MySQL server started by Akonadi) has it set (line 48).

> Are you aware of that options? Did you consider it?
> 
> It might be useful to have:
> 
> akonadictl vacuum
> 
> have actually really reclaim disk space with MySQL default backend.

That does reclaim disk space here.

> I do not know whether its actually doing something on my Akonadi started
> PostgreSQL setup since it returns within a fraction of a second and I do
> not see much activity. But then thats still KDEPIM 4.4.11 and only
> contacts in there, so probably not much to do. Oh yes, this seems to do
> something according to ~/.xsession-errors:
> 
> "vacuuming database, that'll take some time and require a lot of temporary
> disk space..."
> "optimizing table SchemaVersionTable..."
> "optimizing table ResourceTable..."
> "optimizing table CollectionTable..."
> "optimizing table MimeTypeTable..."
> "optimizing table PimItemTable..."
> "optimizing table FlagTable..."
> "optimizing table PartTable..."
> "optimizing table CollectionAttributeTable..."
> "optimizing table PimItemFlagRelation..."
> "optimizing table CollectionMimeTypeRelation..."
> "optimizing table CollectionPimItemRelation..."
> "vacuum done"

Yes, akonadictl just issues a D-Bus command to the server to perform the 
vacuum, so it'll indeed returns immediately. The actual vacuum happens in the 
background and takes several minutes and needs a lot of temporary disk space 
here.

regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120810/6bbf5f62/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/