@zwovierzwo
die mit Abstand größten Tabellen sind bei mir apcontact mit 4,6GB und contact mit 4,3 GB. Friendica löscht wohl auch keine inaktiven Kontakt und mit dem größer werdenden Fediverse werden wohl auch die potentiellen Kontakte mehr. Wäre schön wenn man da mal aufräumen könnte. Meine kleine Instanz hat jetzt auch langsam eine 22GB große Datenbank und das erscheint mir wirklich ein bisschen zu groß.
@powo01 Aktuell 90 Tage. Ich habe jedoch die 30 Tage auch ausprobiert, in der Hoffnung auf eine Abflachung der Kurve. Fehlanzeige, das muss etwas anderes sein.
@zwovierzwo@powo01@abu
Nach dem Umstellen des Wertes, muss Du ein OPTIMZE fahren.
Das ist wie eine Defragmentierung bei HDD´s.
Nur weil Beiträge gelöscht werden, wir die Datenbankdatei nicht kleiner. Gelöschte Beiträge machen Speicherplatz in der Datei frei, welcher wieder belegt werden kann, verkleinert aber nicht die Datenbank.
Das Verkleinern macht dann das OPTIMZE - die Datenbanktabellen werden dann ohne Lücken neu aufgebaut.
Das Ergebnis ist eine kleinere Datenbank auf dem Storage.
@zwovierzwo Ich frage mich auch, warum #Friendica eine solche Riesendatenbank generiert. Meine Ein-User-Instanz hat nach kurzer Zeit bereits 1 GB... @helpers
@Hiker
nun ich hab auch nur 2 User hier laufen und die läuft ca. 1,5 - 2 Jahre.
Ich hab auch keine Ahnung was da alles drinnen steht.
Parallel hab ich nun eine Sharkey (Misskey) Instanz am laufen - mal schauen wie sich da die Datenbank entwickelt.
@zwovierzwo@Hiker
Räume die DB von Zeit zu Zeit auf, damit der Platz wieder freigegeben wird.
Die DB hier ist ≈50 GB groß, läuft seit fast einen Jahrzehnt und beherbergt einige hundert User.
@nick@feb@Hiker@zwovierzwo
Nur MyISAM Tabllen unterstützen eine Optimierung.
InnoDB halt nicht.
Das Ergebnis ist nahezu das gleiche. MyISAM kann "on the fly" optimiert werden, InnoDB nicht.
Bei InnoDB wir die Tabelle Analysiert und und dann ohne Lücken neu erstellt (also sauber kopiert) - von daher die Meldung.
@raroun Das löst #Friendica, je nach Einstellung selber aus. Aber wenn die Datenbank gross oder riesig wird, wird das offenbar ein langer Prozess. Mein Provider hat mich gemahnt, das sei zu lang, da würde der automatische Backup-Prozess gestört... @zwovierzwo@nick@feb
@zwovierzwo@nick@feb@Hiker
Nicht alle Tabellen werden von Friendica automatisch optimiert.
Die Dauer der Optimierung hängt stark von der zur Verfügung stehen Leistung ab.
Hier dauert die Optimierung einer kompletten 160gbyte großen Friendica Datenbank derzeit ca.25 Minuten.
@raroun Ja und wenn genau in diese Zeit das Backup laufen soll, dann gibts einen Konflikt - Backup einer Datenbank, die gerade neu geschrieben wird, ist relativ schwierig... @zwovierzwo@nick@feb
@zwovierzwo@nick@feb@Hiker
Das geht problemlos mit Dateisystem-Snapshots, machen wir auch so.
Be einem Shared hoster ist es leider schwierig nachvollziehen, bzw. zu erahnen wie dort die Datensicherungen durchgeführt werden.
Eine Lösung hierfür habe ich nicht, aber vielleicht kann man mit dem Anbieter kommunizieren und eine Lösung finden, die beide Seiten zufrieden stellt.
Sollte dies fehlschlagen - aus welchem Grund auch immer - Anbieterwechsel und vorher die Anforderungen schildern.
@Hiker@feb@zwovierzwo
Die Nutzerzahl ist gar nicht so entscheidend - eher wie stark die Instanz "vernetzt" ist und ob relay Server abonniert sind, oder halt nicht.
@feb Aber wenn auf einer Ein-User-Instanz die Datenbank innert paar Monaten über 1 GB gross wird (trotz der automatischen Optimierung durch Friendica) und der Provider reklamiert, der Backup-Prozess werden immer wieder gestört, wirft das Fragen auf.
Wenn ich den Provider richtig verstanden habe, wird jedes Mal, wenn worker gestartet wird (also relativ oft (alle 10 Min zB), wird auch an den Tabellen optimiert. @zwovierzwo
Add comment