[gelöst] DBLog / MariaDB - optimizeTables verringert die physische Größe nicht

[t1me2die]

Moin zusammen,

ich habe eine MariaDB im Einsatz, wo ich fleißig Datensätze logge.
Hab die DB am Wochenende neu aufgesetzt, weil der Speicher voll war und ich von Null beginnen wollte.

Nun läuft täglich ein at, der mit einem "reduceLog" Datensätze löscht.
Im Anschluss folgt ein "optimizeTables", wo eine Reduzierung der Größe (MB) ersichtlich ist.

Wenn ich nun aber in den Ordner /var/lib/mysql/fhem/ schaue und mir die dort liegende "history.ibd"-Datei anschaue, wächst diese weiter.

Gehe ich richtig der Annahme, dass ein optimizeTables, wie ein VAKUUM arbeitet und die physische Dateigröße von der Datenbank nach einem reduceLog verringern sollte?
Oder bleibt die physische Dategröße von der Datenbank erhalten und der Speicherbereich in der Datenbank (dort wo die gelöschten Datensätze mal standen) wird nur intern freigegeben - ich gewinne aber keinen physischen Speicherplatz auf dem Laufwerk?

Danke für eure Aufklärung.

Gruß
Mathze

[ch.eick]

ich habe eine MariaDB im Einsatz, wo ich fleißig Datensätze logge.
Hab die DB am Wochenende neu aufgesetzt, weil der Speicher voll war und ich von Null beginnen wollte.

Nun läuft täglich ein at, der mit einem "reduceLog" Datensätze löscht.
Im Anschluss folgt ein "optimizeTables", wo eine Reduzierung der Größe (MB) ersichtlich ist.

Wenn ich nun aber in den Ordner /var/lib/mysql/fhem/ schaue und mir die dort liegende "history.ibd"-Datei anschaue, wächst diese weiter.

Gehe ich richtig der Annahme, dass ein optimizeTables, wie ein VAKUUM arbeitet und die physische Dateigröße von der Datenbank nach einem reduceLog verringern sollte?
Oder bleibt die physische Dategröße von der Datenbank erhalten und der Speicherbereich in der Datenbank (dort wo die gelöschten Datensätze mal standen) wird nur intern freigegeben - ich gewinne aber keinen physischen Speicherplatz auf dem Laufwerk?

Hallo Mathze,

ich habe zwar kein MarieDB mehr im Einsatz, da es mir mit der nicht gepflegten Version 5 langsam zu kritisch wurde.
Aber in der aktuellen MySQL 8.0.28 läuft es wie es soll.

Beim optimize table wird eine temporäre kopie angelegt, die dann später zum neuen Datenbank File wird.
Danach ist der nicht mehr verwendete Platz innerhalb des Files weg und somit wird auch auf dem System der Platz nicht mehr weiter belegt.
Das hat bei mir dann jetzt 892 Mb frei gegeben.

Code Auswählen Erweitern


pi@raspberrypi:~/docker-compose/fhem_2022/mysql/data/fhem $ ls -l
insgesamt 8589440
-rw-r----- 1 27 sudo     114688 Jan 27 15:35  current.ibd
-rw-r----- 1 27 sudo 7088373760 Jan 27 15:50  history.ibd
-rw-r----- 1 27 sudo 1707081728 Jan 27 15:47 '#sql-ib1070-173004618.ibd'
pi@raspberrypi:~/docker-compose/fhem_2022/mysql/data/fhem $ ls -l
insgesamt 6090868
-rw-r----- 1 27 sudo     114688 Jan 27 15:35 current.ibd
-rw-r----- 1 27 sudo 6236930048 Jan 27 17:14 history.ibd
pi@raspberrypi:~/docker-compose/fhem_2022/mysql/data/fhem $

Solltest Du noch mehr Platz Probleme haben, dann gibt es wohl auch die Möglichkeit die EVENT Spalte nicht zu schreiben, das macht pro Zeile
durchaus 1/3 an Platz aus. Ich habe es jedoch selber noch nicht probiert.

VG
   Christian

[t1me2die]

Moin Christian,

ich habe nun über das Terminal mein Glück probiert.

Code Auswählen Erweitern


1. DB via "set devie reopen 7200" abhängen
2. mysql -u admin -p
3. use fhem;
4. optimize table history;
5. DB via "set device reopen" wieder anhängen


Wie du schon sagtest, es wird eine DB Kopie angelegt, konnte dies auch via WinSCP live verfolgen und die Größe verringerte sich von 151MB auf 131MB.
Also bedeutet es, dass OPTIMIZE TABLE zumindest via Terminal funktioniert, also muss ich einen Fehler bei meinem DbRep Device haben.

List von meinem DbRep:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DATABASE   fhem
   DEF        myDbLog
   FUUID      61f27a0e-f33f-5a17-cf74-258501cfa2c43b54
   FVERSION   93_DbRep.pm:v8.47.0-s25492/2022-01-17
   LASTCMD    optimizeTables
   MODEL      Client
   NAME       optimizeDbLog
   NOTIFYDEV  global,optimizedDbLog
   NR         34689
   NTFY_ORDER 50-optimizedDbLog
   ROLE       Client
   STATE      Beginn: 115.27 MB - Ende: 111.25 MB
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE myDbLog
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.47.0
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1643280910.58782
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2022-01-28 02:00:08   SizeDbBegin_MB  115.27
     2022-01-28 02:00:08   SizeDbEnd_MB    111.25
     2022-01-28 02:00:08   afteroptimize_message Reopen executed.
     2022-01-28 02:00:08   state           WARNING - optimize finished, but message after command appeared
Attributes:
   DbLogExclude .*
   allowDeletion 1
   executeAfterProc set myDbLog reopen
   executeBeforeProc set myDbLog reopen 7200
   room       LogDB
   stateFormat Beginn: SizeDbBegin_MB MB - Ende: SizeDbEnd_MB MB
   verbose    0


Das Device wird 1x am Tag um 2Uhr mit optimizeTables aufgerufen:

Code Auswählen Erweitern


Internals:
   CFGFN     
   COMMAND    set optimizeDbLog optimizeTables
   DEF        *02:00:00 set optimizeDbLog optimizeTables
   FUUID      61f27ba3-f33f-5a17-78c9-3470ff567af19277
   NAME       t_optimizeTables
   NR         34801
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 02:00:00
   TIMESPEC   02:00:00
   TRIGGERTIME 1643418000
   TRIGGERTIME_FMT 2022-01-29 02:00:00
   TYPE       at
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1643281315.45836
           VALUE      Next: 02:00:00
   READINGS:
     2022-01-28 02:00:00   state           Next: 02:00:00
Attributes:
   DbLogExclude .*
   room       LogDB


In der Konsole bekomme ich folgende Ausgabe:

Code Auswählen Erweitern


MariaDB [fhem]> optimize table history;
+--------------+----------+----------+-------------------------------------------------------------------+
| Table        | Op       | Msg_type | Msg_text                                                          |
+--------------+----------+----------+-------------------------------------------------------------------+
| fhem.history | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| fhem.history | optimize | status   | OK                                                                |
+--------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (13.57 sec)


Die Frage ist, warum funktioniert optimizeTables nicht über das DbRep Device?

Gruß

[ch.eick]

Moin Christian,

ich habe nun über das Terminal mein Glück probiert.

Code Auswählen Erweitern


1. mysql -u admin -p
2. use fhem;
3. optimize table history;


Wie du schon sagtest, es wird eine DB Kopie angelegt, konnte dies auch via WinSCP live verfolgen und die Größe verringerte sich von 151MB auf 131MB.
Also bedeutet es, dass OPTIMIZE TABLE zumindest via Terminal funktioniert, also muss ich einen Fehler bei meinem DbRep Device haben.

Die Frage ist, warum funktioniert optimizeTables nicht über das DbRep Device?

Moin

Ich weiß nicht wie Heiko das im DbRep umgesetzt hat. Beim DbRep muss natürlich auf Kompatibilität zu allen Datenbanken geachtet werden, was manchmal zu unterschiedlichen Umsetzungen führen kann.

Eventuell machst Du mal eine Verpointerung im DbRep Thread, dann wird Heiko sicher darauf reagieren.

Gruß
    Christian

[DS_Starter]

Hallo zusammen,

im DbRep wird bei MySQL ebenfalls ein

optimize table <Table>

ausgeführt.
Und amn sieht ja auch an deinen Readings die Veränderung:

Code Auswählen Erweitern


READINGS:
     2022-01-28 02:00:08   SizeDbBegin_MB  115.27
     2022-01-28 02:00:08   SizeDbEnd_MB    111.25


Oder übersehe ich etwas an deiner Fragestellung ?`

Grüße,
Heiko

[t1me2die]

Moin Heiko, da hast du vollkommen recht, diese optimize Table Funktion habe ich versucht zu verwenden.
Wie du siehst, bekomme ich auch Readings zurückgeliefert, die physische Datenbank hat sich aber leider nicht verkleinert.
Also die Größe der History Datei im Verzeichnis bleibt unverändert.

Wenn ich wiederum die Optimize Table Funktion via Terminal ausführe, dann kann ich live via WinSCP verfolgen, wie ein Recreate der Tabelle erfolgt und wie die Tabelle im Verzeichnis schrumpft.

Gerne werde ich das noch einmal genau protokollieren, einmal auf dem Weg über das DbRep Device und einmal via Terminal.

Gruß
Mathze

[DS_Starter]

hmmm, mehr als "optimize table .." kann ich ja auch nicht aufrufen.
Muss ich mal bei mir vergleichen wie sich das verhält.

MIt verbose 5 im Device habe ich es mir angeschaut, sieht erstmal ganz normal aus:

Code Auswählen Erweitern


2022.01.28 10:57:41.534 3: DbRep Rep.LogMariaVM.Test - ################################################################
2022.01.28 10:57:41.535 3: DbRep Rep.LogMariaVM.Test - ###          New optimize table / vacuum execution           ###
2022.01.28 10:57:41.536 3: DbRep Rep.LogMariaVM.Test - ################################################################
2022.01.28 10:57:41.608 4: DbRep Rep.LogMariaVM.Test - Database connect - user: fhemtest, UTF-8 option set: yes
2022.01.28 10:57:41.618 4: DbRep Rep.LogMariaVM.Test - Searching for tables inside database fhemtest....
2022.01.28 10:57:41.626 5: DbRep Rep.LogMariaVM.Test - ......... Table definition found: .........
2022.01.28 10:57:41.627 5: DbRep Rep.LogMariaVM.Test - Avg_row_length: 311
2022.01.28 10:57:41.628 5: DbRep Rep.LogMariaVM.Test - Collation: utf8_bin
2022.01.28 10:57:41.629 5: DbRep Rep.LogMariaVM.Test - Comment:
2022.01.28 10:57:41.630 5: DbRep Rep.LogMariaVM.Test - Create_options:
2022.01.28 10:57:41.630 5: DbRep Rep.LogMariaVM.Test - Create_time: 2022-01-12 20:43:51
2022.01.28 10:57:41.631 5: DbRep Rep.LogMariaVM.Test - Data_free: 0
2022.01.28 10:57:41.631 5: DbRep Rep.LogMariaVM.Test - Data_length: 49152
2022.01.28 10:57:41.632 5: DbRep Rep.LogMariaVM.Test - Engine: InnoDB
2022.01.28 10:57:41.632 5: DbRep Rep.LogMariaVM.Test - Index_length: 0
2022.01.28 10:57:41.633 5: DbRep Rep.LogMariaVM.Test - Max_data_length: 0
2022.01.28 10:57:41.633 5: DbRep Rep.LogMariaVM.Test - Name: current
2022.01.28 10:57:41.634 5: DbRep Rep.LogMariaVM.Test - Row_format: Compact
2022.01.28 10:57:41.634 5: DbRep Rep.LogMariaVM.Test - Version: 10
2022.01.28 10:57:41.634 5: DbRep Rep.LogMariaVM.Test - ......... Table definition END ............
2022.01.28 10:57:41.635 5: DbRep Rep.LogMariaVM.Test - ......... Table definition found: .........
2022.01.28 10:57:41.635 5: DbRep Rep.LogMariaVM.Test - Avg_row_length: 137
2022.01.28 10:57:41.636 5: DbRep Rep.LogMariaVM.Test - Collation: utf8_bin
2022.01.28 10:57:41.636 5: DbRep Rep.LogMariaVM.Test - Comment:
2022.01.28 10:57:41.637 5: DbRep Rep.LogMariaVM.Test - Create_options:
2022.01.28 10:57:41.637 5: DbRep Rep.LogMariaVM.Test - Create_time: 2022-01-12 20:43:52
2022.01.28 10:57:41.638 5: DbRep Rep.LogMariaVM.Test - Data_free: 7340032
2022.01.28 10:57:41.638 5: DbRep Rep.LogMariaVM.Test - Data_length: 847216640
2022.01.28 10:57:41.639 5: DbRep Rep.LogMariaVM.Test - Engine: InnoDB
2022.01.28 10:57:41.639 5: DbRep Rep.LogMariaVM.Test - Index_length: 760119296
2022.01.28 10:57:41.640 5: DbRep Rep.LogMariaVM.Test - Max_data_length: 0
2022.01.28 10:57:41.640 5: DbRep Rep.LogMariaVM.Test - Name: history
2022.01.28 10:57:41.640 5: DbRep Rep.LogMariaVM.Test - Row_format: Compact
2022.01.28 10:57:41.641 5: DbRep Rep.LogMariaVM.Test - Version: 10
2022.01.28 10:57:41.642 5: DbRep Rep.LogMariaVM.Test - ......... Table definition END ............
2022.01.28 10:57:41.651 5: DbRep Rep.LogMariaVM.Test - current query: SELECT sum( data_length + index_length ) / 1024 / 1024 FROM information_schema.TABLES where table_schema='fhemtest' 
2022.01.28 10:57:41.657 3: DbRep Rep.LogMariaVM.Test - Size of database fhemtest before optimize (MB): 1532.92
2022.01.28 10:57:41.658 3: DbRep Rep.LogMariaVM.Test - Optimizing tables
2022.01.28 10:57:41.659 3: DbRep Rep.LogMariaVM.Test - Optimizing table `current` (INNODB). It will take a while.
2022.01.28 10:57:41.871 3: DbRep Rep.LogMariaVM.Test - Table 1 `current` optimized successfully.
2022.01.28 10:57:41.872 3: DbRep Rep.LogMariaVM.Test - Optimizing table `history` (INNODB). It will take a while.
2022.01.28 11:08:53.676 3: DbRep Rep.LogMariaVM.Test - Table 2 `history` optimized successfully.
2022.01.28 11:08:53.769 3: DbRep Rep.LogMariaVM.Test - 2 tables have been optimized.
2022.01.28 11:08:53.784 3: DbRep Rep.LogMariaVM.Test - Size of database fhemtest after optimize (MB): 1202.05
2022.01.28 11:08:53.809 3: DbRep Rep.LogMariaVM.Test - Optimize tables of database fhemtest finished - total time used (hh:mm:ss): 00:11:12
2022.01.28 11:08:53.867 3: DbRep Rep.LogMariaVM.Test - Optimize tables finished successfully.


[t1me2die]

Also ich habe mal fix mit verbose 5 ein optimizeTable aufgerufen:

Code Auswählen Erweitern


2022.01.28 11:34:13 3: DbRep optimizeDbLog - ################################################################
2022.01.28 11:34:13 3: DbRep optimizeDbLog - ###          New optimize table / vacuum execution           ###
2022.01.28 11:34:13 3: DbRep optimizeDbLog - ################################################################
2022.01.28 11:34:13 3: DbRep optimizeDbLog - execute command before optimize: 'set myDbLog reopen 7200'
2022.01.28 11:34:13 2: DbLog myDbLog: Connection closed until 13:34:13 (7200 seconds).
2022.01.28 11:34:13 4: DbRep optimizeDbLog - Database connect - user: admin, UTF-8 option set: yes
2022.01.28 11:34:13 4: DbRep optimizeDbLog - Searching for tables inside database fhem....
2022.01.28 11:34:13 5: DbRep optimizeDbLog - ......... Table definition found: .........
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Avg_row_length: 0
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Collation: utf8_bin
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Comment:
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Create_options:
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Create_time: 2022-01-28 02:00:00
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Data_free: 0
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Data_length: 16384
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Engine: InnoDB
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Index_length: 0
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Max_data_length: 0
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Name: current
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Row_format: Compact
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Version: 10
2022.01.28 11:34:13 5: DbRep optimizeDbLog - ......... Table definition END ............
2022.01.28 11:34:13 5: DbRep optimizeDbLog - ......... Table definition found: .........
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Avg_row_length: 148
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Collation: utf8_bin
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Comment:
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Create_options:
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Create_time: 2022-01-28 09:28:59
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Data_free: 6291456
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Data_length: 102367232
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Engine: InnoDB
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Index_length: 29999104
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Max_data_length: 0
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Name: history
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Row_format: Compact
2022.01.28 11:34:13 5: DbRep optimizeDbLog - Version: 10
2022.01.28 11:34:13 5: DbRep optimizeDbLog - ......... Table definition END ............
2022.01.28 11:34:13 5: DbRep optimizeDbLog - current query: SELECT sum( data_length + index_length ) / 1024 / 1024 FROM information_schema.TABLES where table_schema='fhem' 
2022.01.28 11:34:13 3: DbRep optimizeDbLog - Size of database fhem before optimize (MB): 126.25
2022.01.28 11:34:13 3: DbRep optimizeDbLog - Optimizing tables
2022.01.28 11:34:13 3: DbRep optimizeDbLog - Optimizing table `current` (INNODB). It will take a while.
2022.01.28 11:34:13 3: DbRep optimizeDbLog - Table 1 `current` optimized successfully.
2022.01.28 11:34:13 3: DbRep optimizeDbLog - Optimizing table `history` (INNODB). It will take a while.
2022.01.28 11:34:25 3: DbRep optimizeDbLog - Table 2 `history` optimized successfully.
2022.01.28 11:34:25 3: DbRep optimizeDbLog - 2 tables have been optimized.
2022.01.28 11:34:25 3: DbRep optimizeDbLog - Size of database fhem after optimize (MB): 131.28
2022.01.28 11:34:25 3: DbRep optimizeDbLog - Optimize tables of database fhem finished - total time used (hh:mm:ss): 00:00:11
2022.01.28 11:34:25 4: DbRep optimizeDbLog - execute command after optimize: 'set myDbLog reopen'
2022.01.28 11:34:25 2: DbRep optimizeDbLog - command message after optimize: "Reopen executed."
2022.01.28 11:34:25 3: DbRep optimizeDbLog - Optimize tables finished successfully


Irgendwie passt die dort genannte Größe aber nicht mit der tatsächlichen Größe auf dem Laufwerk:

Code Auswählen Erweitern


root@debian-jessie-final:/var/lib/mysql/fhem# ls -l
insgesamt 151664
-rw-rw---- 1 mysql mysql      3179 Jan 28 11:34 current.frm
-rw-rw---- 1 mysql mysql     98304 Jan 28 11:34 current.ibd
-rw-rw---- 1 mysql mysql        54 Jan 24 22:38 db.opt
-rw-rw---- 1 mysql mysql      3668 Jan 28 11:34 history.frm
-rw-rw---- 1 mysql mysql 155189248 Jan 28 11:38 history.ibd


Oder sehe ich das falsch?

Gruß
Mathze

[DS_Starter]

Kennst du / ihr ein besseres Statement um die Datengröße zu bestimmen als ich es verwende ?

Code Auswählen Erweitern


SELECT sum( data_length + index_length ) / 1024 / 1024 FROM information_schema.TABLES where table_schema='fhem'


[ch.eick]

Kennst du / ihr ein besseres Statement um die Datengröße zu bestimmen als ich es verwende ?

Code Auswählen Erweitern


SELECT sum( data_length + index_length ) / 1024 / 1024 FROM information_schema.TABLES where table_schema='fhem'


Nein, wieso?

Nur halt für alle Tabellen

Code Auswählen Erweitern


SELECT table_schema "DB Name",
       Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
  FROM  information_schema.tables
  GROUP BY table_schema;

Ich denke aber, dass die Tabellen Größe, nach einem Delete von der Dateigröße abweicht.
Früher (<== wie ich das hasse ) , haben wir im Rechenzentrum jede Nacht eine Optimierung durchgeführt, um die Dateien auf der Platte zu verkleinern, bevor ein Cold Backup auf Tape geschrieben wurde

[Wernieman]

OT:
Wobei ein "OptimizeTable" die interne Optimierung von MySQL für die Jeweilige DB durcheinanderbringt. FHEM ist jetzt nicht unbedingt der "High-MySQL-User", aber trotzdem .....

Was auch gerne vergessen wird: Wenn ich ein Datensatz lösche, wird zwar das Datenbankfile nicht kleiner, der Platz aber beim nächsten anlegen von Dateien verwendet.

Also unabhängig on diesem Problem: ist es wirklich Sinnvoll, täglich das DB-File zu "verkleinern"?
Und "Platzproblem" hört sich nach Pi an, da ist dieses für die Lebensdauern einer SDCard sehr kontraproduktiv ....

[DS_Starter]

Also unabhängig on diesem Problem: ist es wirklich Sinnvoll, täglich das DB-File zu "verkleinern"?

Nein ist es nicht. Eigentlich nur wenn größere Datenmengen in der DB gelöscht werden. Sonst ist das unsinnig.
Und du hast natürlich auch recht mit dem Hinweis dass natürlich der intern freigegebene Datenplatz wieder für neue Daten verwendet wird nach dem Löschen.
Deswegen reicht ab und zu ein optimize wenn man möchte.

[ch.eick]

OT:
Wobei ein "OptimizeTable" die interne Optimierung von MySQL für die Jeweilige DB durcheinanderbringt. FHEM ist jetzt nicht unbedingt der "High-MySQL-User", aber trotzdem .....

Was auch gerne vergessen wird: Wenn ich ein Datensatz lösche, wird zwar das Datenbankfile nicht kleiner, der Platz aber beim nächsten anlegen von Dateien verwendet.

Also unabhängig on diesem Problem: ist es wirklich Sinnvoll, täglich das DB-File zu "verkleinern"?
Und "Platzproblem" hört sich nach Pi an, da ist dieses für die Lebensdauern einer SDCard sehr kontraproduktiv ....

Ein aktueller Pi sollte mit einer SSD betrieben werden Niemals eine Datenbank auf eine SDCard ablegen !!!
Ich mache sowas auch nicht täglich, sondern eher 3-4 x im Jahr.

Mehr Platz würde man sparen, wenn man die Event Spalte nicht füllt, das kann bis zu 1/3 ausmachen. Was nicht gespeichert wird, spart schon vorher Platz.

[t1me2die]

Bei mir läuft FHEM in einer VM auf einem RAID1.
Der VM hatte ich Anfangs nur 64GB zugewiesen, mittlerweile habe ich erweitert auf 256GB.
Zu meiner Schande muss ich zugeben, dass ich ein aufräumen einfach verpennt hatte in der Vergangenheit, weswegen meine DB Größe auf 52GB anwuchs mit 200Mio Datensätze.
Dementsprechend war da nicht mehr soviel zu retten, denn ohne Speicherplatz konnte ein Optimize Table auch nicht so recht funktionieren.
Aus diesem Grund habe ich einmal von vorne angefangen und bin aktuell dabei mir ein "Aufräum-Plan" zu erstellen im Sinne von täglicher Datenreduktion und ggf. optimizing.

Die Reduktion funktioniert und kann ich auch nachvollziehen, bei der Optimize Funktion hätte ich dasselbe erwartet, wie ich vorhin im Terminal gepostet habe.

Gruß
Mathze

[t1me2die]

Gut, ich werde das mal weiter beobachten und ggf. berichten.

Zwischen einem optimizeTables über das DbRep Device und der Eingabe OPTIMIZE TABLE über die Konsole sind die Ergebnisse unmittelbar hintereinander jedoch unterschiedlich.

Ausführung von OPTIMIZE TABLE über die Konsole:

Code Auswählen Erweitern


root@debian-jessie-final:~# cd /var/lib/mysql/fhem/
root@debian-jessie-final:/var/lib/mysql/fhem# ls -l
insgesamt 159856
-rw-rw---- 1 mysql mysql      3179 Jan 28 11:34 current.frm
-rw-rw---- 1 mysql mysql     98304 Jan 28 11:34 current.ibd
-rw-rw---- 1 mysql mysql        54 Jan 24 22:38 db.opt
-rw-rw---- 1 mysql mysql      3668 Jan 28 11:34 history.frm
-rw-rw---- 1 mysql mysql 163577856 Jan 28 13:10 history.ibd
root@debian-jessie-final:/var/lib/mysql/fhem# mysql -u admin -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6144
Server version: 10.1.48-MariaDB-0+deb9u2 Debian 9.13

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> use fhem;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [fhem]> optimize table history;
+--------------+----------+----------+-------------------------------------------------------------------+
| Table        | Op       | Msg_type | Msg_text                                                          |
+--------------+----------+----------+-------------------------------------------------------------------+
| fhem.history | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| fhem.history | optimize | status   | OK                                                                |
+--------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (13.03 sec)

MariaDB [fhem]> exit
Bye
root@debian-jessie-final:/var/lib/mysql/fhem# ls -l
insgesamt 139376
-rw-rw---- 1 mysql mysql      3179 Jan 28 11:34 current.frm
-rw-rw---- 1 mysql mysql     98304 Jan 28 11:34 current.ibd
-rw-rw---- 1 mysql mysql        54 Jan 24 22:38 db.opt
-rw-rw---- 1 mysql mysql      3668 Jan 28 13:11 history.frm
-rw-rw---- 1 mysql mysql 142606336 Jan 28 13:12 history.ibd
root@debian-jessie-final:/var/lib/mysql/fhem#


Gut, ich werde nun erstmal paar Wochen paar Daten sammeln und dann schaue ich, wie sich ein reduceLog mit einem einmal monatlichen optimizeTable verhält.
Erst einmal recht herzlichen Dank für eure Unterstützung und ein sonniges WE 

Gruß
Mathze