Skip to main content

Was mach ich jetzt mit Friendica? Datenbank läuft voll. - What do I do with Friendica now? Database running out of space.

Frage an die #frindica Experten hier im #fediverse :

Bis vor einigen Tagen lief meine Friendica-instanz prima. Also... sie läuft auch jetzt noch prima.
Ich hatte ja, nachdem ich ein paar Versuche mit Friendica-Servern gemacht hatte und mir das zu speicherhungrig war, es im Juni (am 4.) nochmal einen Versuch gestartet. Und ich habe die Optimierungen aus dem Admin-Handbuch durchgführt.
Maximales Alter der Elemente in der Suchtabelle auf 14 Tage gesetzt, Lebensdauer von Beiträgen anderer Knoten auch auf 14 Tage gesetzt, Lebensdauer nicht angeforderter Beiträge dito, Lebensdauer der Beiträge auch 14 Tage. Optimiere die Tabellen regelmäßig eingeschaltet, Kontaktprofilbilder zwischenspeichern ausgeschaltet, Datenbank aufräumen eingeschaltet.

Und tatsächlich hielt sich der Speicherverbrauch in normalen Grenzen (in etwa im Rahmen dessen, was z.B. mein Hubzilla-Hub auch belegt). Doch nun habe ich heute mal geschaut, wie es so aussieht, mit dem Speicherplatz... und ich bin erschrocken. Die Datenbank ist auf über 50 GB angewachsen (zum Vergleich: mein Hubzilla-Hub, der seit mehreren Jahren läuft, der mehr Benutzer hat - bei Friendica bin nur ich registriert - und bei dem ich ungefähr die doppelte Zahl an Kontakten habe, kommt mit nicht einmal 8 GB aus... bei Streams ist es ähnlich, wobei der Hub auch erst so lange läuft wie meine Friendica-Instanz... da sind es um die 6 GB bei einigen Nutzerkonten und identischen Verbindungszahlen).

Das ist doch nicht normal! In den Logs hab ich keine Auffälligkeiten gefunden. 51 GB find ich jetzt schon heftig.

Vor allem, hab ich keine Idee, wie ich die DB jetzt "abspecken" könnte. Und wenn das so weiter geht mit dem steigenden Speicherplatzverbrauch, läuft irgendwan auch mal die Platte voll... darauf hab ich nun gar keine Lust.

Was kann ich tun? Woran mag es liegen?

Bin geneigt, wenn ich das nicht kurzfristig abgestellt bekomme, Friendica als selbst betriebene Instanz echt zu den Akten zu legen.

Mein Friendica 2024.03 läuft auf einem VPS, Intel Xeon Processor (Skylake, IBRS), 4 Kerne, 16 GB RAM, 150 GB SSD, Debian Linux 11.10, MariaDB 10.5.23, installiert mit YunoHost 11.2.20.2 (stable).

Question for the #frindica experts here at #fediverse :

Until a few days ago my Friendica instance was running fine. Well... it's still running fine now.
After I had made a few attempts with Friendica servers and found it too memory-hungry, I gave it another try in June (on the 4th). And I carried out the optimisations from the admin manual.
Maximum age of elements in the search table set to 14 days, lifetime of posts from other nodes also set to 14 days, lifetime of unrequested posts ditto, lifetime of posts also 14 days. Optimise tables regularly switched on, cache contact profile images switched off, clean up database switched on.

And the memory consumption was in fact within normal limits (roughly in line with what my Hubzilla hub uses, for example). But now I've had a look today to see how things are going with the memory... and I'm shocked. The database has grown to over 50 GB (for comparison: my Hubzilla hub, which has been running for several years, which has more users - only I am registered with Friendica - and where I have about twice the number of contacts, doesn't even manage with 8 GB... It's similar with Streams, although the hub has only been running for as long as my Friendica instance... It's around 6 GB with some user accounts and identical connection numbers).

That's not normal! I didn't find any anomalies in the logs. I think 51 GB is already a lot.

Above all, I have no idea how I could "slim down" the DB now. And if this continues with the increasing memory consumption, the disc will fill up at some point... I'm not in the mood for that.

What can I do? What might be the problem?

If I can't get this to stop in the short term, I'm inclined to really shelve Friendica as a self-operated instance.

My Friendica 2024.03 runs on a VPS, Intel Xeon processor (Skylake, IBRS), 4 cores, 16 GB RAM, 150 GB SSD, Debian Linux 11.10, MariaDB 10.5.23, installed with YunoHost 11.2.20.2 (stable).

in reply to pepecyb (Friendica)

Tuxi ⁂
Tuxi ⁂
• •
@pepecyb (Friendica)
Mir fällt gerade ein, dass es so ein Befehl auf der DB-Konsole gibt, die die DB bereinigt oder komprimiert. Habe das vor langem mal bei mir gemacht und es hat doch einiges gebracht.
Ich habe gerade in der Hilfe oder im Wiki geschaut und leider nichts gefunden was das genau war. Ich komme ums verrecken einfach nicht drauf. Es war irgendein SQL-Befehl. 🤔
Vielleicht weiß @Michael Vogel was ich meine?
in reply to pepecyb (Friendica)

Michael Vogel
Michael Vogel
• •
Zunächst einmal: schaue nach, welche Tabellen die meisten Daten verbrauchen. Sollte "storage" sehr weit oben sein, deaktiviere "Kontaktprofilbilder zwischenspeichern" in den "Performance"-Einstellungen.
in reply to Michael Vogel

pepecyb (Friendica)
pepecyb (Friendica)
• •

Es ist tatsächlich "storage"... das hatte ich schon nachgeschaut.

Das Zwischenspeichern ist von Anfang an ausgeschaltet.

Und jegliches Zwischenspeichern auf 14 Tage eingestellt... auch von Anfang an.

Außerdem ist die automatische Datenbankbereinigung aktiviert.

Hab heute mal etwas genauer in die DB geschaut. In der Tabelle "post" sind über 33.000 Einträge, deren Eingangsdatum (teilweise wesentlich) älter als 14 Tage sind.

in reply to pepecyb (Friendica)

Michael Vogel
Michael Vogel
• •

Der Platzverbraucher ist "Storage". Die ganzen anderen Einstellungen sind für den konkreten Fall tatsächlich irrelevant.

Was ergeben diese beiden Kommandos?
select count(*) from photo where `backend-class` = 'Database' and `backend-ref` in (select id from storage);
und:
select count(*) from photo where `backend-class` = 'Database' and not `backend-ref` in (select id from storage);

Außerdem führe bitte das Kommando hier aus:
select uid,count(*) as total from photo where `backend-class` = 'Database' and `backend-ref` in (select id from storage) group by uid order by total;

⇧