Skip to main content


Hinweis an alle meine Kontakte, die ich bei #friendica (Peperica - friendica.pepecyb.de) als pepecyb(Friendica) habe:

Heute (14.07.2024) im Laufe des Tages werde ich sämtliche Verbindungen meines Accounts bei Peperica löschen und anschließend Friendica vom Server putzen.

Wie ich ja schon geschrieben hatte, hat meine Friendica-Instanz aus unerfindlichen Gründen vor ein paar Tagen die Datenbank auf über 51 GB aufgeblasen. Nach etwas über einem Monat Laufzeit dieser Ein-Nutzer-Instanz (es hat sich keiner registriert... zum Glück) und 101 Kontakten, sind alsi 51 GB an Daten angefallen... wenn das so weiter ginge, dann müsste ich mein Server-Paket aber mal mächtig aufstocken. Echt mal... darauf habe ich keine Lust!

Ich hatte meine Probleme an verschiedenen Stellen geschildert. Die Ansätze zur Problemfindung, die mir angetragen wurden, waren fundiert, aber die hatte ich alle auch schon abgeklopft und die Einstellungen dieser Instanz so gewählt, dass die DB eigentlich nicht hätte so anwachsen dürfen (ja, auch das Speichern von Profilfotos war abgeschaltet).

Die einzige Möglichkeit, die DB zu schrumpfen wären manuelle Interventionen in der mysql-shell-hell. Und weil ich nicht weiß, woran der plötzliche Anstieg des Speicherbedarfs aus heiterem Himmel lag (und es scheinbar auch nicht herausfinden kann), bestünde natürlich auch die Möglichkeit, dass das immer wieder vorkommt. Und damit müsste ich mich regelmäßig durch die DB wühlen und per Hand aufräumen und ausmisten. Das ist jezt nicht mene Vorstellung vom Betrieb einer Fediverse-Instanz, zumal ich solche Probleme z.B. von Hubzilla nicht kenne (ich betreibe Hubzilla-Hubs schon seit 2016 und hatte immer einen in Betrieb).

Deshalb wird die Instanz gelöscht. Mit der Zeit, die ich für die Pflege aufwenden müsste, kann ich wirklich besseres anfangen. Ist für mich auch kein Drama, da sich die Kontakte, die ich bei Friendica habe (bald gehabt habe 😉 😁) auch bei meinem Hubzilla-Kanal "Der Pepe (Hubzilla)" wiederfinden.

Also: Bei Peperica bin ich spätestens ab morgen nicht mehr erreichbar (weil es kein "Peperica" mehr gibt)... dafür aber wie immer und dauerhaft bei meinem Hub Whoville: pepecyb@hub.hubzilla.hu

Schade, weil Friendica einiges umsetzt bzw. anbietet, was bei Hubzilla nicht, oder nicht ganz so komfortabel vorhanden ist. Trotzdem bietet mir #hubzilla alles, was ich brauche und erwarte... und es macht keine seltsamen Sachen.

in reply to Der Pepe (Hubzilla) ⁂

@Der Pepe (Hubzilla) ich hatte ein fast ähnliches Verhalten meiner Datenbank beobachtet nach dem Update mit Datenbank Änderungen. Ist meinen Datenbank von 30GB auf 59 GB angestiegen ( Instanz ist etwas älter als ein Jahr und hat 33 User ). Bei mir hat ein
sudo mysqloptimize DATENBANKNAME geholfen und die Datenbank war nur noch 34GB groß.

Edit: Sehe gerade deine Instanz ist nicht wie meinen auf RC, also kann das Datenbank Update nicht der Grund sein aber vielleicht hilft es trotzdem

This entry was edited (1 month ago)
in reply to OldKid ⁂

@OldKid Ich bin auch nicht auf RC (nie). Trotzdem wächst meine DB stetig an und die alten Posts werden nachweislich nicht oder zumindest nicht korrekt gelöscht. Die Anzahl der Instanzen mit DB-Problemen ist schon etwas auffällig. Deshalb werde ich beim nächsten grösseren Problem auch den Stecker ziehen.

@Der Pepe (Hubzilla)

in reply to alfredb

Hi @alfredb wie genau findet mal solche alten Posts in der DB und wie löschst Du sie?
in reply to RockyIII

@RockyIII Es ist relativ kompliziert, wenn man alles erwischen will. Es sind acht Tabellen betroffen, die alle über eine weitere Tabelle verbunden sind. Eine detaillierte Anleitung möchte ich hier lieber nicht abgeben, ich würde mich dann bei möglichen Fehlschlägen irgendwie verantwortlich fühlen.
in reply to alfredb

@alfredb ok aber das Prinzip könntest Du hier beschreiben
in reply to RockyIII

@RockyIII Das Prinzip:

  • Erstelle eine Liste aller Posts mit Erstelldatum mehr als <n> Tage zurück.
  • Lösche diese Posts
  • Lösche alle verbundenen Datensätze anhand der Liste
  • Optimiere alle bearbeiteten Tabellen

<n> = Benutzer-Einstellung

in reply to OldKid ⁂

Danke @OldKid fürs erinnern. Habe heute gleich mal wieder diese Aktion ausgeführt. Somit ist meine DB um 52 GB schlanker. 😀

C.c.: @Der Pepe (Hubzilla)

in reply to OldKid ⁂

@Der Pepe (Hubzilla) @OldKid Bei meiner kleinen "Einzelbenutzer" (nicht wirklich, da meine Frau noch drauf ist) habe ich folgende Groessen:

Daten: 13,704,859,728
Index: 3,387,527,192

Ich bin aber auch viele grosse Instanzen am Blockieren, da diese mich auch blockieren. Es liegt wohl daran, weshalb deine Datenbank nur anwaechst, weil fremde Instanzen ihre Beitraege bei dir "einlagern".

in reply to Roland Häder

@OldKid @Der Pepe (Hubzilla) Und stelle mal die Einstellung fuer den Speicherort von Dateien um: /admin/storage, Bei mir verschlingt die Tabelle 8 GB.
in reply to Roland Häder

@Roland Häder
Aber 8 GB bleiben doch 8 GB. Egal ob in einer DB oder in einer "Datei-Storage". Oder habe ich da einen Denkfehler?
in reply to Tuxi ⁂

@Tuxi :Friendica: 🐧 ✅ Mir fällt da als Begründung direkt ein, dass die DB ein eigenes Filesystem hat.

@Roland Häder

in reply to Hamiller Friendica

@Hamiller Friendica
Versehe ich trotzdem nicht. Auch dort bleiben es doch die gleichen 8 GB.
Sorry für die dumme Fragerei, aber Datenbanken sind für mich "böhmische Dörfer".
in reply to Tuxi ⁂

@Tuxi :Friendica: 🐧 ✅ Ich bin bei dem Thema leider auch nicht mehr auf dem aktuellsten Stand.

Ich kann mir das nur so vorstellen, dass die Partition für die Datenbank bei einer Trennung diese 8 GB noch zusätzlich Luft zum Wachsen hat.

This entry was edited (1 month ago)
in reply to Der Pepe (Hubzilla) ⁂

Das hätte bei meinem Problem leider nix gebracht. Der Avatar-Cache war ausgeschaltet. Es waren mit Sicherheit die nicht gelöschten "alten" Postings. Da scheint die automatische Bereinigung beim Worker nicht richtig zu funktionieren.
in reply to Der Pepe (Hubzilla)

@Der Pepe (Hubzilla)
Wie kann ich denn überprüfen, ob ich nicht gelöschte alte Postings habe?
in reply to Der Pepe (Hubzilla)

Nein. Du hattest doch ein paar Queries ausgeführt. Und die haben ganz eindeutig gezeigt, dass die storage-Tabelle mit 39,3 GB den meisten Platz verbraucht hat. Diese Tabelle wird für den Avatar-Cache verwendet. Die erste Tabelle, die etwas mit Beiträgen zu tun hat, verbraucht weniger als 700 MB.

Und die anderen Queries haben eindeutig gezeigt, dass in der Storage-Tabelle so um die 64.000 Einträge waren. Und das wäre mit meinem PR beseitigt worden, so dass das System nach einem optimize über 30 GB weniger Platz verbraucht hätte.

in reply to Michael Vogel

Sag mal @Michael Vogel darf ich Dich zu deinem PR was fragen?
Läuft diese Bereinigung automatisch, über eine Einstellung in der Adminoberfläche oder über die Console?
in reply to Tuxi ⁂

Im Moment geht das nur über die Konsole. Es war als schnelle Lösung gedacht.
in reply to Michael Vogel

@Michael Vogel
Okay Danke. Dann warte ich mal, das der PR freigegeben wird und schaue wie das auf der Console ausschaut.
in reply to Tuxi ⁂

Das Kommando ist in Verbindung mit dem Deaktivieren des Cachings von Avatar-Bildern sinnvoll. Ich muss noch einmal einen Blick auf ein paar Automatiken werfen, die den Cache bei nur bei wirklich aktiven Kontakten verwenden und bei den anderen löschen.
in reply to Der Pepe (Hubzilla) ⁂

In der DB_Tabelle "post" gibt es eine Spalte mit dem Eingangsdatum (kann jetzt nicht mehr nachschauen, wie die genau bezeichnet ist, weil mein Friendica bereits weggeputzt ist). Nicht mit dem Erstellungsdatum verwechseln. Das ist nicht maßgeblich, weil auch ältere Postings mal in die Timeline gespült werden, z.B. wenn ein Kontakt liked oder einen Kommentar dazu abgibt.
in reply to Der Pepe (Hubzilla)

Ich finde es übrigens mehr als schade, dass Du so schnell nach dem Post im Forum aufgegeben hast. Es war ja nicht so, dass da keine Antwort gekommen wäre. Und ich hatte extra einige Daten erfragt und habe dann angefangen, daran zu arbeiten. Ich habe dann mehrere Stunden am Abend und am Vormittag damit verbracht, mich um das Problem zu kümmern und eine Lösung zu suchen, zu erarbeiten und zu testen, um dann einen Pull Request zu erstellen - nur um dann zu erfahren, dass Du Dein System bereits gelöscht hast.
in reply to Der Pepe (Hubzilla) ⁂

@Michael Vogel Sorry, ich hatte nicht mitbekommen, dass Du da wirklich intensiv dran arbeitest. Generell scheint es aber sinnvoll - auch ohne dass ich eine Instanz beteibe - an dem Problem zu arbeiten, denn es scheint ja ein generelles Problem zu sein.
In meinem Foren-Post hatte ich im Ausgangs-Posting geschrieben, dass ich erwäge, mich von Friendica zu verabschieden. Schade, weil ich es für ein tolles System halte... aber ich bin da inzwischen, nachdem ich etliche Dienste im Laufe des vergangenen Jahres getestet hatte, nicht mehr sehr "geduldig".

Vor allem aber hat mich das Verhalten meiner Instanz echt erschreckt. Sie lief auf einem VPS, wo auch mein Hub Whoville und mein Streams-Hub Nomád laufen (neben einigen anderen Diensten). Und die Friendica-Instanz hat es vollbracht, in wenigen Tagen über 48 GB zuzulegen und 51 GB zu verbrauchen... damit war von meinen "spärlichen" 150 GB SSD-Platz nur noch knapp 1/4 frei. Was, wenn in den nächsten Tagen der nächste "Schub" gekommen wäre? Platte voll, System erstmal lahmgelegt... darauf hatte ich wirklich keine Lust. Allein schon ein Backup (was ich, solange ich noch alleine auf der Instanz unterwegs war, nur wöchentlich gemacht habe), war nicht mehr möglich (dadurch bin ich überhaupt erst darauf aufmerksam geworden).

Klar... es wäre möglich "zu Fuß" per SQL die betroffenen Tabellen (insb. "post") von Altlasten zu bereinigen. Aber da bin ich wohl zu "verwöhnt" von Hubzilla (und Streams), wo das nicht notwendig ist und die automatische Bereinigung einfach funktioniert. Friendica war für mich eh nur ein "Bonus-System", das ich zusätzlich zu meinen Hubs betreiben wollte.

Bitte nicht böse sein... ich hoffe, Du kommst dem Problem trotzdem auf die Spur... das wird vielen Instanz-Betreibern sicher helfen.