[vz-dev] Hinweis für vzcompress2 o.Ä.-Nutzer: OPTIMIZE TABLE nicht vergessen

Florian Knodt f.knodt at yotaweb.de
Fri Dec 20 18:30:28 CET 2013


Nabend zusammen,

mir ist eben aufgefallen, dass trotz vcompress2 meine Datenbankdatei
immer weiter (bzw. schneller als erwartet) wächst. Bei MyISAM war die
Sache recht einfach: Wenn der Überhang wuchs war das Mittel der Wahl ja
ein OPTIMIZE TABLE, beim hier verwendeten InnoDB scheint das etwas
komplexer zu sein, da diese Engine offenbar kein separates OPTIMIZE
unterstützt sondern hierbei die komplette Tabelle neu erstellt.

Erst mal vorab: Es bringt nichtsdestotrotz den von mir gewünschten
erfolg, meine Datenbank ist von knapp 800 auf nun 150MB geschrumpft -
kommt sicherlich auch der Performance zu Gute.

Im Internet findet mach häufig den Rat bei InnoDB keinen Optimize
durchzuführen, sondern die Indizes zu löschen und neu zu erstellen.
Diese Methode ist deutlich schneller fertig und beansprucht den Speicher
weniger, da nur die Indizes neu geschrieben werden und nicht der
komplette Datenbestand. Der Nachteil dürfte diese Methode allerdings für
die integration in einen Cronjob o.Ä. uninteressant machen: Während des
Erstellens gibt es keine Indizes, Leseoperationen dürften - wenn sie
nicht sogar in einen Timeout laufen - ewig dauern und ich bin mir nicht
einmal sicher, ob in der Zeit Daten aufgezeichnet werden können (data
basiert auf IDs die per AUTO INCREMENT vergeben werden und das ist afair
an einen Index gebunden).

Ein OPTIMIZE TABLE alle Nase lang dürfte als Cron auf "richtigen"
Servern sicher nicht Schaden - die Datenbank war hier während des Laufes
komplett funktionsfähig und die benötigte Zeit hielt sich bei meinem
System in Grenzen (bisher nicht komplett gestoppt, aber <5 Minuten).
Wenn jemand auf seinem Raspi schon regelmäßige OPTIMIZE TABLE ausführt
wäre ein Erfahrungsbericht nicht schlecht, ich würde schätzen, dass die
Last ein Problem werden könnte. Auch die Hohe IO-Last dürfte der SD
nicht gut tun (bessere Karten könnten eventuell durch den freien
Speicher die Abnutzung wieder vesser verteilen was dann wiederum
ausgleichen würde). Bei solchen Systemen würde ich eher erst mal nur das
Testsystem quählen.

-- 
Mit freundlichen Grüßen  ||  Sincerely yours
Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
www.adlerweb.info · www.56648.de · @adlerweb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20131220/eb870754/attachment.pgp>


More information about the volkszaehler-dev mailing list