Hubzilla: Datenbank verkleinern und aufbl\u00e4hen verhindern \u2013 ein Erfahrungsbericht<\/strong>
Hubzilla: Datenbank verkleinern und aufbl\u00e4hen verhindern<\/h1>
Hubzilla: Datenbank verkleinern und aufbl\u00e4hen verhindern<\/h1>Ein Erfahrungsbericht<\/h2>\u2605Geschrieben von einem verwundertem Hubzilla-Admin\u2605
Hinweis:<\/strong> Alle SQL-Operationen wurden mit Backup durchgef\u00fchrt. Bitte immer zuerst ein Backup der Datenbank erstellen bevor man Eingriffe vornimmt.
Das Problem<\/mark><\/h3>Ich bin Hubzilla-Anf\u00e4nger, meine Instanz habe ich Mitte Februar aufgesetzt. Nach ziemlich genau einem Monat hatte sie bereits eine Gr\u00f6\u00dfe von \u00fcber 3,4 GB<\/strong>, was ja jetzt nicht tragisch ist wenn man bedenkt was alles an importierten Inhalten als Blob gespeichert wird. Aber ich hab mir das mal hochgerechnet und dachte: In 6 Monaten ist so dann mein 20 GB-Datenbankspeicher voll.
Der Cron-Job schien also nicht das zu tun was man erwartet, OPTIMIZE TABLE<\/strong> in MySQL brachte auch nichts. Ich hatte im Admin-Men\u00fc eine Ablaufzeit von 4 Tagen eingestellt, mir schien logisch, jetzt niedriger eingestellt, desto eher werden Inhalte gel\u00f6scht \u2013 aber die Datenbank wuchs trotzdem unaufh\u00f6rlich. Ich dachte, muss ich wohl den \u00f6ffentlichen Stream deaktivieren, was ich aber auch nicht wollte.
Nach einer Recherche und Analyse habe ich wohl die Ursache gefunden. Und ich versuche das jetzt mal zu dokumentieren.
Die Ursache: Drei versteckte Probleme<\/mark><\/h3>Problem 1:<\/strong> Das Admin-Men\u00fc setzt den falschen Konfigurationsschl\u00fcssel
Im Admin-Men\u00fc unter \/admin\/site<\/strong> kann man eine Ablaufzeit f\u00fcr Inhalte einstellen. Ich hatte dort 4 Tage eingetragen \u2013 in der \u00dcberzeugung, dass alte Fremdinhalte oder eigene nach 4 Tagen gel\u00f6scht werden. Die Formulierung war mit nicht so ganz klar.
Was das Admin-Men\u00fc wirklich tut: Es setzt default_expire_days<\/strong> und active_expire_days<\/strong>. Der Expire-Daemon der f\u00fcr f\u00f6derierte Fremdinhalte zust\u00e4ndig ist liest aber sys_expire_days<\/strong> \u2013 und dieser Wert war bei mir leer, also 0, somit \u201eniemals l\u00f6schen\u201d.
Das kann man nur per Kommandozeile pr\u00fcfen:<\/strong>
php util\/config system sys_expire_days<\/code><\/pre>
Ergebnis:<\/strong> config[system][sys_expire_days] = (leer!)
W\u00e4hrend im Admin-Men\u00fc alles korrekt aussah, hat der Daemon seit Wochen nichts gel\u00f6scht.
Problem 2: expire_limit war zu niedrig<\/strong>
Der Expire-Daemon l\u00f6scht standardm\u00e4\u00dfig nur 5.000 Eintr\u00e4ge pro Cron-Lauf. Bei einer Datenbank mit \u00fcber 87.000 angesammelten Remote-Items h\u00e4tte das Monate gedauert \u2013 vorausgesetzt sys_expire_days<\/strong> w\u00e4re \u00fcberhaupt gesetzt gewesen.
Problem 3: InnoDB gibt Speicher nicht automatisch frei<\/strong>
Selbst wenn Eintr\u00e4ge als gel\u00f6scht markiert werden, gibt MySQL\/InnoDB den Speicherplatz nicht automatisch ans Betriebssystem zur\u00fcck. Daf\u00fcr ist OPTIMIZE TABLE<\/strong> n\u00f6tig \u2013 aber das war ebenfalls deaktiviert.
Die Diagnose<\/mark><\/h3>Zuerst habe ich mir die gr\u00f6\u00dften Tabellen angeschaut:
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND((data_length+index_length)\/1024\/1024, 2) AS total_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY (data_length+index_length) DESC LIMIT 10;<\/code><\/pre>
Ergebnis bei mir:<\/strong>
![\"tabelle1.png\"](\"https:\/\/voidofxulub.com\/photo\/ad63e1a1-a80a-4c15-93cc-18d2a6d3bbef-2.png\" "\\"tabelle1.png\\"")
<\/a>
Gesamt:<\/strong> \u00fcber 3,4 GB<\/strong> \u2013 und das auf einer kleinen privaten Einzel-Instanz nach 4 Wochen.
Dann habe ich gepr\u00fcft wie viele Remote-Items sich angesammelt hatten:
SELECT COUNT(*) FROM item WHERE item_origin = 0;<\/code><\/pre>
-- Ergebnis: 87.633<\/strong>
SELECT COUNT(*) FROM item \nWHERE item_origin = 0 \nAND created < DATE_SUB(NOW(), INTERVAL 5 DAY);<\/code><\/pre>
-- Ergebnis: 64.727 (h\u00e4tten l\u00e4ngst gel\u00f6scht sein sollen!)<\/strong>
64.727 Items die laut meiner Admin-Einstellung h\u00e4tten gel\u00f6scht sein sollen \u2013 aber nie gel\u00f6scht wurden.
Die L\u00f6sung<\/mark><\/h3>Schritt 1:<\/mark><\/h3> Die fehlenden Konfigurationswerte \u00fcber SSH setzen
cd \/pfad\/zu\/hubzilla<\/code><\/pre>
DER wichtigste Befehl \u2013 das war die Hauptursache:
php util\/config system sys_expire_days 30<\/code><\/pre>
Expire-Limit erh\u00f6hen damit der Daemon schneller arbeitet:
php util\/config system expire_limit 50000<\/code><\/pre>
OPTIMIZE automatisch nach dem L\u00f6schen ausf\u00fchren:
php util\/config system optimize_items 1<\/code><\/pre>
Lieferberichte deaktivieren (f\u00fcr mich unn\u00f6tig, frisst Platz):
php util\/config system disable_dreport 1<\/code><\/pre>
Zur Kontrolle aller Werte:
php util\/config system | grep -i expire<\/code><\/pre>
-- Ausgabe SSH:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
config[system][register_expire] = 3d
config[system][default_expire_days] = 30
config[system][active_expire_days] = 30
config[system][last_expire_day] = 24
config[system][expire_limit] = 50000
config[system][sys_expire_days] = 30<\/code><\/pre>
Schritt 2: Den Expire-Daemon manuell ansto\u00dfen<\/mark><\/h3>Da sich ein R\u00fcckstau angesammelt hatte, habe ich den Daemon manuell mehrfach ausgef\u00fchrt:
php Zotlabs\/Daemon\/Master.php Expire<\/code><\/pre>
Mehrfach wiederholen bis sich kaum noch etwas \u00e4ndert
Schritt 3: Cache und Lieferberichte leeren<\/mark><\/h3>
TRUNCATE TABLE cache;\nTRUNCATE TABLE dreport;\n<\/code><\/pre>
Der Cache wird automatisch neu bef\u00fcllt \u2013 das Leeren ist v\u00f6llig sicher.
Schritt 4: Bereits gel\u00f6schte Items physisch entfernen<\/h3>
DELETE FROM item WHERE item_deleted = 1 LIMIT 50000;\nDELETE FROM item WHERE item_pending_remove = 1 LIMIT 50000;<\/code><\/pre>
Schritt 5: OPTIMIZE ausf\u00fchren<\/h3>
OPTIMIZE TABLE item;\nOPTIMIZE TABLE term;\nOPTIMIZE TABLE iconfig;\nOPTIMIZE TABLE cache;\nOPTIMIZE TABLE dreport;<\/code><\/pre>
Hinweis: information_schema<\/strong> zeigt bei InnoDB oft veraltete Gr\u00f6\u00dfen. Die echte Gr\u00f6\u00dfe pr\u00fcft man so (mit eigenem Datenbanknamen anpassen):
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND(data_free\/1024\/1024, 2) AS free_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY data_length DESC LIMIT 10;<\/code><\/pre>
Das Ergebnis<\/mark><\/strong>
![\"tabelle2.png\"](\"https:\/\/voidofxulub.com\/photo\/306ff31f-d7ae-4998-850f-d9f218ade7e6-2.png\" "\\"tabelle2.png\\"")
<\/a>
\u00dcber 2,6 GB eingespart \u2013 mehr als 75% Reduktion<\/strong><\/span><\/mark>
Warum passiert das \u00fcberhaupt?<\/mark><\/h3>Hubzilla ist ein f\u00f6deriertes Netzwerk. Jeder Hub speichert Beitr\u00e4ge aus dem gesamten Fediverse lokal \u2013 \u00e4hnlich wie ein E-Mail-Server alle empfangenen Mails speichert. Ohne Ablaufeinstellung w\u00e4chst die Datenbank unbegrenzt.
Das Problem: Die Ablaufeinstellung im Admin-Men\u00fc (default_expire_days) und der tats\u00e4chlich wirksame Konfigurationsschl\u00fcssel (sys_expire_days) sind zwei verschiedene Dinge. Keine Ahnung warum das so ist, aber es ist zumindest ein Dokumentationsproblem, grade f\u00fcr unbedarfte Admins. Man liest ja auch oft von eben diesem Problem der sich aufbl\u00e4henden Datenbank.
Langfristige Empfehlungen<\/mark><\/h3>Diese Einstellungen sollte man setzen:<\/strong>
Remote-Inhalte nach 30 Tagen l\u00f6schen<\/strong>
php util\/config system sys_expire_days 30<\/code><\/pre>
Schnellere Bereinigung<\/strong>
php util\/config system expire_limit 50000 <\/code><\/pre>
Automatisch Speicher freigeben<\/strong>
php util\/config system optimize_items 1 <\/code><\/pre>
Lieferberichte deaktivieren<\/strong>
php util\/config system disable_dreport 1 <\/code><\/pre>
Und regelm\u00e4\u00dfig pr\u00fcfen:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
Fazit<\/mark><\/h3>Das Admin-Men\u00fc von Hubzilla suggeriert eine funktionierende Ablaufkonfiguration, die in Wirklichkeit den falschen Konfigurationsschl\u00fcssel setzt. Ohne dieses Wissen kann eine Hubzilla-Instanz \u00fcber Jahre hinweg unkontrolliert wachsen, obwohl man glaubt alles richtig konfiguriert zu haben.
\u00dcbrigens zum Schluss am besten im Admin-Men\u00fc die Ablaufzeit auch auf 30 Tage stellen damit alles synchron ist.
Ich hoffe dieser Bericht hilft anderen Hubzilla-Admins die das gleiche Problem haben. Aber zum Schlu\u00df nochmal der Hinweis: Ohne Backup der Datenbank keine Befehle einfach nach tippen.<\/div><\/div>
<\/div>","width":640,"height":426}
Hinweis:<\/strong> Alle SQL-Operationen wurden mit Backup durchgef\u00fchrt. Bitte immer zuerst ein Backup der Datenbank erstellen bevor man Eingriffe vornimmt.
Das Problem<\/mark><\/h3>Ich bin Hubzilla-Anf\u00e4nger, meine Instanz habe ich Mitte Februar aufgesetzt. Nach ziemlich genau einem Monat hatte sie bereits eine Gr\u00f6\u00dfe von \u00fcber 3,4 GB<\/strong>, was ja jetzt nicht tragisch ist wenn man bedenkt was alles an importierten Inhalten als Blob gespeichert wird. Aber ich hab mir das mal hochgerechnet und dachte: In 6 Monaten ist so dann mein 20 GB-Datenbankspeicher voll.
Der Cron-Job schien also nicht das zu tun was man erwartet, OPTIMIZE TABLE<\/strong> in MySQL brachte auch nichts. Ich hatte im Admin-Men\u00fc eine Ablaufzeit von 4 Tagen eingestellt, mir schien logisch, jetzt niedriger eingestellt, desto eher werden Inhalte gel\u00f6scht \u2013 aber die Datenbank wuchs trotzdem unaufh\u00f6rlich. Ich dachte, muss ich wohl den \u00f6ffentlichen Stream deaktivieren, was ich aber auch nicht wollte.
Nach einer Recherche und Analyse habe ich wohl die Ursache gefunden. Und ich versuche das jetzt mal zu dokumentieren.
Die Ursache: Drei versteckte Probleme<\/mark><\/h3>Problem 1:<\/strong> Das Admin-Men\u00fc setzt den falschen Konfigurationsschl\u00fcssel
Im Admin-Men\u00fc unter \/admin\/site<\/strong> kann man eine Ablaufzeit f\u00fcr Inhalte einstellen. Ich hatte dort 4 Tage eingetragen \u2013 in der \u00dcberzeugung, dass alte Fremdinhalte oder eigene nach 4 Tagen gel\u00f6scht werden. Die Formulierung war mit nicht so ganz klar.
Was das Admin-Men\u00fc wirklich tut: Es setzt default_expire_days<\/strong> und active_expire_days<\/strong>. Der Expire-Daemon der f\u00fcr f\u00f6derierte Fremdinhalte zust\u00e4ndig ist liest aber sys_expire_days<\/strong> \u2013 und dieser Wert war bei mir leer, also 0, somit \u201eniemals l\u00f6schen\u201d.
Das kann man nur per Kommandozeile pr\u00fcfen:<\/strong>
php util\/config system sys_expire_days<\/code><\/pre>
Ergebnis:<\/strong> config[system][sys_expire_days] = (leer!)
W\u00e4hrend im Admin-Men\u00fc alles korrekt aussah, hat der Daemon seit Wochen nichts gel\u00f6scht.
Problem 2: expire_limit war zu niedrig<\/strong>
Der Expire-Daemon l\u00f6scht standardm\u00e4\u00dfig nur 5.000 Eintr\u00e4ge pro Cron-Lauf. Bei einer Datenbank mit \u00fcber 87.000 angesammelten Remote-Items h\u00e4tte das Monate gedauert \u2013 vorausgesetzt sys_expire_days<\/strong> w\u00e4re \u00fcberhaupt gesetzt gewesen.
Problem 3: InnoDB gibt Speicher nicht automatisch frei<\/strong>
Selbst wenn Eintr\u00e4ge als gel\u00f6scht markiert werden, gibt MySQL\/InnoDB den Speicherplatz nicht automatisch ans Betriebssystem zur\u00fcck. Daf\u00fcr ist OPTIMIZE TABLE<\/strong> n\u00f6tig \u2013 aber das war ebenfalls deaktiviert.
Die Diagnose<\/mark><\/h3>Zuerst habe ich mir die gr\u00f6\u00dften Tabellen angeschaut:
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND((data_length+index_length)\/1024\/1024, 2) AS total_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY (data_length+index_length) DESC LIMIT 10;<\/code><\/pre>
Ergebnis bei mir:<\/strong>
<\/a>
Gesamt:<\/strong> \u00fcber 3,4 GB<\/strong> \u2013 und das auf einer kleinen privaten Einzel-Instanz nach 4 Wochen.
Dann habe ich gepr\u00fcft wie viele Remote-Items sich angesammelt hatten:
SELECT COUNT(*) FROM item WHERE item_origin = 0;<\/code><\/pre>
-- Ergebnis: 87.633<\/strong>
SELECT COUNT(*) FROM item \nWHERE item_origin = 0 \nAND created < DATE_SUB(NOW(), INTERVAL 5 DAY);<\/code><\/pre>
-- Ergebnis: 64.727 (h\u00e4tten l\u00e4ngst gel\u00f6scht sein sollen!)<\/strong>
64.727 Items die laut meiner Admin-Einstellung h\u00e4tten gel\u00f6scht sein sollen \u2013 aber nie gel\u00f6scht wurden.
Die L\u00f6sung<\/mark><\/h3>Schritt 1:<\/mark><\/h3> Die fehlenden Konfigurationswerte \u00fcber SSH setzen
cd \/pfad\/zu\/hubzilla<\/code><\/pre>
DER wichtigste Befehl \u2013 das war die Hauptursache:
php util\/config system sys_expire_days 30<\/code><\/pre>
Expire-Limit erh\u00f6hen damit der Daemon schneller arbeitet:
php util\/config system expire_limit 50000<\/code><\/pre>
OPTIMIZE automatisch nach dem L\u00f6schen ausf\u00fchren:
php util\/config system optimize_items 1<\/code><\/pre>
Lieferberichte deaktivieren (f\u00fcr mich unn\u00f6tig, frisst Platz):
php util\/config system disable_dreport 1<\/code><\/pre>
Zur Kontrolle aller Werte:
php util\/config system | grep -i expire<\/code><\/pre>
-- Ausgabe SSH:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
config[system][register_expire] = 3d
config[system][default_expire_days] = 30
config[system][active_expire_days] = 30
config[system][last_expire_day] = 24
config[system][expire_limit] = 50000
config[system][sys_expire_days] = 30<\/code><\/pre>
Schritt 2: Den Expire-Daemon manuell ansto\u00dfen<\/mark><\/h3>Da sich ein R\u00fcckstau angesammelt hatte, habe ich den Daemon manuell mehrfach ausgef\u00fchrt:
php Zotlabs\/Daemon\/Master.php Expire<\/code><\/pre>
Mehrfach wiederholen bis sich kaum noch etwas \u00e4ndert
Schritt 3: Cache und Lieferberichte leeren<\/mark><\/h3>
TRUNCATE TABLE cache;\nTRUNCATE TABLE dreport;\n<\/code><\/pre>
Der Cache wird automatisch neu bef\u00fcllt \u2013 das Leeren ist v\u00f6llig sicher.
Schritt 4: Bereits gel\u00f6schte Items physisch entfernen<\/h3>
DELETE FROM item WHERE item_deleted = 1 LIMIT 50000;\nDELETE FROM item WHERE item_pending_remove = 1 LIMIT 50000;<\/code><\/pre>
Schritt 5: OPTIMIZE ausf\u00fchren<\/h3>
OPTIMIZE TABLE item;\nOPTIMIZE TABLE term;\nOPTIMIZE TABLE iconfig;\nOPTIMIZE TABLE cache;\nOPTIMIZE TABLE dreport;<\/code><\/pre>
Hinweis: information_schema<\/strong> zeigt bei InnoDB oft veraltete Gr\u00f6\u00dfen. Die echte Gr\u00f6\u00dfe pr\u00fcft man so (mit eigenem Datenbanknamen anpassen):
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND(data_free\/1024\/1024, 2) AS free_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY data_length DESC LIMIT 10;<\/code><\/pre>
Das Ergebnis<\/mark><\/strong>
<\/a>
\u00dcber 2,6 GB eingespart \u2013 mehr als 75% Reduktion<\/strong><\/span><\/mark>
Warum passiert das \u00fcberhaupt?<\/mark><\/h3>Hubzilla ist ein f\u00f6deriertes Netzwerk. Jeder Hub speichert Beitr\u00e4ge aus dem gesamten Fediverse lokal \u2013 \u00e4hnlich wie ein E-Mail-Server alle empfangenen Mails speichert. Ohne Ablaufeinstellung w\u00e4chst die Datenbank unbegrenzt.
Das Problem: Die Ablaufeinstellung im Admin-Men\u00fc (default_expire_days) und der tats\u00e4chlich wirksame Konfigurationsschl\u00fcssel (sys_expire_days) sind zwei verschiedene Dinge. Keine Ahnung warum das so ist, aber es ist zumindest ein Dokumentationsproblem, grade f\u00fcr unbedarfte Admins. Man liest ja auch oft von eben diesem Problem der sich aufbl\u00e4henden Datenbank.
Langfristige Empfehlungen<\/mark><\/h3>Diese Einstellungen sollte man setzen:<\/strong>
Remote-Inhalte nach 30 Tagen l\u00f6schen<\/strong>
php util\/config system sys_expire_days 30<\/code><\/pre>
Schnellere Bereinigung<\/strong>
php util\/config system expire_limit 50000 <\/code><\/pre>
Automatisch Speicher freigeben<\/strong>
php util\/config system optimize_items 1 <\/code><\/pre>
Lieferberichte deaktivieren<\/strong>
php util\/config system disable_dreport 1 <\/code><\/pre>
Und regelm\u00e4\u00dfig pr\u00fcfen:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
Fazit<\/mark><\/h3>Das Admin-Men\u00fc von Hubzilla suggeriert eine funktionierende Ablaufkonfiguration, die in Wirklichkeit den falschen Konfigurationsschl\u00fcssel setzt. Ohne dieses Wissen kann eine Hubzilla-Instanz \u00fcber Jahre hinweg unkontrolliert wachsen, obwohl man glaubt alles richtig konfiguriert zu haben.
\u00dcbrigens zum Schluss am besten im Admin-Men\u00fc die Ablaufzeit auch auf 30 Tage stellen damit alles synchron ist.
Ich hoffe dieser Bericht hilft anderen Hubzilla-Admins die das gleiche Problem haben. Aber zum Schlu\u00df nochmal der Hinweis: Ohne Backup der Datenbank keine Befehle einfach nach tippen.<\/div><\/div>
<\/div>","width":640,"height":426}
Im Admin-Men\u00fc unter \/admin\/site<\/strong> kann man eine Ablaufzeit f\u00fcr Inhalte einstellen. Ich hatte dort 4 Tage eingetragen \u2013 in der \u00dcberzeugung, dass alte Fremdinhalte oder eigene nach 4 Tagen gel\u00f6scht werden. Die Formulierung war mit nicht so ganz klar.
Was das Admin-Men\u00fc wirklich tut: Es setzt default_expire_days<\/strong> und active_expire_days<\/strong>. Der Expire-Daemon der f\u00fcr f\u00f6derierte Fremdinhalte zust\u00e4ndig ist liest aber sys_expire_days<\/strong> \u2013 und dieser Wert war bei mir leer, also 0, somit \u201eniemals l\u00f6schen\u201d.
Das kann man nur per Kommandozeile pr\u00fcfen:<\/strong>
php util\/config system sys_expire_days<\/code><\/pre>
Ergebnis:<\/strong> config[system][sys_expire_days] = (leer!)
W\u00e4hrend im Admin-Men\u00fc alles korrekt aussah, hat der Daemon seit Wochen nichts gel\u00f6scht.
Problem 2: expire_limit war zu niedrig<\/strong>
Der Expire-Daemon l\u00f6scht standardm\u00e4\u00dfig nur 5.000 Eintr\u00e4ge pro Cron-Lauf. Bei einer Datenbank mit \u00fcber 87.000 angesammelten Remote-Items h\u00e4tte das Monate gedauert \u2013 vorausgesetzt sys_expire_days<\/strong> w\u00e4re \u00fcberhaupt gesetzt gewesen.
Problem 3: InnoDB gibt Speicher nicht automatisch frei<\/strong>
Selbst wenn Eintr\u00e4ge als gel\u00f6scht markiert werden, gibt MySQL\/InnoDB den Speicherplatz nicht automatisch ans Betriebssystem zur\u00fcck. Daf\u00fcr ist OPTIMIZE TABLE<\/strong> n\u00f6tig \u2013 aber das war ebenfalls deaktiviert.
Die Diagnose<\/mark><\/h3>Zuerst habe ich mir die gr\u00f6\u00dften Tabellen angeschaut:
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND((data_length+index_length)\/1024\/1024, 2) AS total_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY (data_length+index_length) DESC LIMIT 10;<\/code><\/pre>
Ergebnis bei mir:<\/strong>
<\/a>
Gesamt:<\/strong> \u00fcber 3,4 GB<\/strong> \u2013 und das auf einer kleinen privaten Einzel-Instanz nach 4 Wochen.
Dann habe ich gepr\u00fcft wie viele Remote-Items sich angesammelt hatten:
SELECT COUNT(*) FROM item WHERE item_origin = 0;<\/code><\/pre>
-- Ergebnis: 87.633<\/strong>
SELECT COUNT(*) FROM item \nWHERE item_origin = 0 \nAND created < DATE_SUB(NOW(), INTERVAL 5 DAY);<\/code><\/pre>
-- Ergebnis: 64.727 (h\u00e4tten l\u00e4ngst gel\u00f6scht sein sollen!)<\/strong>
64.727 Items die laut meiner Admin-Einstellung h\u00e4tten gel\u00f6scht sein sollen \u2013 aber nie gel\u00f6scht wurden.
Die L\u00f6sung<\/mark><\/h3>Schritt 1:<\/mark><\/h3> Die fehlenden Konfigurationswerte \u00fcber SSH setzen
cd \/pfad\/zu\/hubzilla<\/code><\/pre>
DER wichtigste Befehl \u2013 das war die Hauptursache:
php util\/config system sys_expire_days 30<\/code><\/pre>
Expire-Limit erh\u00f6hen damit der Daemon schneller arbeitet:
php util\/config system expire_limit 50000<\/code><\/pre>
OPTIMIZE automatisch nach dem L\u00f6schen ausf\u00fchren:
php util\/config system optimize_items 1<\/code><\/pre>
Lieferberichte deaktivieren (f\u00fcr mich unn\u00f6tig, frisst Platz):
php util\/config system disable_dreport 1<\/code><\/pre>
Zur Kontrolle aller Werte:
php util\/config system | grep -i expire<\/code><\/pre>
-- Ausgabe SSH:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
config[system][register_expire] = 3d
config[system][default_expire_days] = 30
config[system][active_expire_days] = 30
config[system][last_expire_day] = 24
config[system][expire_limit] = 50000
config[system][sys_expire_days] = 30<\/code><\/pre>
Schritt 2: Den Expire-Daemon manuell ansto\u00dfen<\/mark><\/h3>Da sich ein R\u00fcckstau angesammelt hatte, habe ich den Daemon manuell mehrfach ausgef\u00fchrt:
php Zotlabs\/Daemon\/Master.php Expire<\/code><\/pre>
Mehrfach wiederholen bis sich kaum noch etwas \u00e4ndert
Schritt 3: Cache und Lieferberichte leeren<\/mark><\/h3>
TRUNCATE TABLE cache;\nTRUNCATE TABLE dreport;\n<\/code><\/pre>
Der Cache wird automatisch neu bef\u00fcllt \u2013 das Leeren ist v\u00f6llig sicher.
Schritt 4: Bereits gel\u00f6schte Items physisch entfernen<\/h3>
DELETE FROM item WHERE item_deleted = 1 LIMIT 50000;\nDELETE FROM item WHERE item_pending_remove = 1 LIMIT 50000;<\/code><\/pre>
Schritt 5: OPTIMIZE ausf\u00fchren<\/h3>
OPTIMIZE TABLE item;\nOPTIMIZE TABLE term;\nOPTIMIZE TABLE iconfig;\nOPTIMIZE TABLE cache;\nOPTIMIZE TABLE dreport;<\/code><\/pre>
Hinweis: information_schema<\/strong> zeigt bei InnoDB oft veraltete Gr\u00f6\u00dfen. Die echte Gr\u00f6\u00dfe pr\u00fcft man so (mit eigenem Datenbanknamen anpassen):
SELECT table_name,\nROUND(data_length\/1024\/1024, 2) AS data_mb,\nROUND(data_free\/1024\/1024, 2) AS free_mb\nFROM information_schema.tables\nWHERE table_schema = 'MEINE_DB'\nORDER BY data_length DESC LIMIT 10;<\/code><\/pre>
Das Ergebnis<\/mark><\/strong>
<\/a>
\u00dcber 2,6 GB eingespart \u2013 mehr als 75% Reduktion<\/strong><\/span><\/mark>
Warum passiert das \u00fcberhaupt?<\/mark><\/h3>Hubzilla ist ein f\u00f6deriertes Netzwerk. Jeder Hub speichert Beitr\u00e4ge aus dem gesamten Fediverse lokal \u2013 \u00e4hnlich wie ein E-Mail-Server alle empfangenen Mails speichert. Ohne Ablaufeinstellung w\u00e4chst die Datenbank unbegrenzt.
Das Problem: Die Ablaufeinstellung im Admin-Men\u00fc (default_expire_days) und der tats\u00e4chlich wirksame Konfigurationsschl\u00fcssel (sys_expire_days) sind zwei verschiedene Dinge. Keine Ahnung warum das so ist, aber es ist zumindest ein Dokumentationsproblem, grade f\u00fcr unbedarfte Admins. Man liest ja auch oft von eben diesem Problem der sich aufbl\u00e4henden Datenbank.
Langfristige Empfehlungen<\/mark><\/h3>Diese Einstellungen sollte man setzen:<\/strong>
Remote-Inhalte nach 30 Tagen l\u00f6schen<\/strong>
php util\/config system sys_expire_days 30<\/code><\/pre>
Schnellere Bereinigung<\/strong>
php util\/config system expire_limit 50000 <\/code><\/pre>
Automatisch Speicher freigeben<\/strong>
php util\/config system optimize_items 1 <\/code><\/pre>
Lieferberichte deaktivieren<\/strong>
php util\/config system disable_dreport 1 <\/code><\/pre>
Und regelm\u00e4\u00dfig pr\u00fcfen:<\/strong>
php util\/config system | grep -i expire<\/code><\/pre>
Fazit<\/mark><\/h3>Das Admin-Men\u00fc von Hubzilla suggeriert eine funktionierende Ablaufkonfiguration, die in Wirklichkeit den falschen Konfigurationsschl\u00fcssel setzt. Ohne dieses Wissen kann eine Hubzilla-Instanz \u00fcber Jahre hinweg unkontrolliert wachsen, obwohl man glaubt alles richtig konfiguriert zu haben.
\u00dcbrigens zum Schluss am besten im Admin-Men\u00fc die Ablaufzeit auch auf 30 Tage stellen damit alles synchron ist.
Ich hoffe dieser Bericht hilft anderen Hubzilla-Admins die das gleiche Problem haben. Aber zum Schlu\u00df nochmal der Hinweis: Ohne Backup der Datenbank keine Befehle einfach nach tippen.<\/div><\/div>
<\/div>","width":640,"height":426}