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

Andreas Goetz cpuidle at gmail.com
Fri Dec 20 18:31:58 CET 2013


wer den dev Zweig nutzt kann php misc/tools/aggregate optimize nutzen ->
data und aggregate


2013/12/20 Florian Knodt <f.knodt at yotaweb.de>

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20131220/20b168cd/attachment.html>


More information about the volkszaehler-dev mailing list