Datenbank von Friendica automatisch aufräumen
Was sind denn gute #Werte für die #Lebendauer von #Beiträgen?
Standard ist ja 90 Tage. Das düfte aber die Datenbank extrem groß anschwellen lassen.
@Friendica Support
Standard ist ja 90 Tage. Das düfte aber die Datenbank extrem groß anschwellen lassen.
@Friendica Support
Raroun
•Das ist individuell sehr unterschiedlich.
Es gibt Instanzen die halten 6 Monate alles vor, es gibt Instanzen die halten lediglich 14 Tage etwas vor.
Im Endeffekt kommt es auf die verfügbaren Ressourcen und Deiner persönlichen Einstellung an. Die Standardwerte finde ich schon ziemlich ausgewogen.
Die Posts an sich sind gar nicht so groß, aber das "Kontaktbilder zwischenspeichern" in Verbindung mit der automatischen Suche von Kontakten macht viel Speicherplatz aus.
Crazy-to-Bike
•Hm. Zwischengespeicherte Bilder sollten doch im Dateisystem landen, oder werden die nicht als jpg o.ä. sondern nur binär in der Datenbank gespeichert?
Es ist jedenfalls schon krass, dass ein sql.gz #Datenbank #Dump von meiner wenige Tage alten Single User #Friendica Instanz gestern Abend schon ~ 300 MB groß war.
Rechne ich das auf 90 Tage hoch, werden das ~ 10 GB.
Dabei ist der Speicherplatz wohl weniger das Problem als die Performance bei einer so fetten Datenbank.
Der Dump einer Nextcloud mit über 100 Nutzern, sehr vielen synchronisieren Dateien, Group Folder und intensiver Kalender- und Adressbuch-Nutzung ist nach Jahren gerade mal ~ 35 MB groß.
@Friendica Support
Heiko
•Du kannst in der Administration festlegen, wo Du speichern willst; ob in der Datenbank oder im Dateisystem (natürlich möglichst oberhalb Deines zugänglichen Webverzeichnis 😉).
Crazy-to-Bike
•Ok. Danke.
Performanter ist beim Laden allerdings vermutlich die Datenbank, wie voreingestellt 🤔
@Raroun @Friendica Support
Raroun
•Sofern nicht anders eingestellt, ist das Standard-Speicherbackend die Datenbank. Das kann man unter unter
Administration / Speicher
prüfen.Auf unserer Mehrbenutzerinstanz pendelt sich die Datenbank bei ca. 100GB ein - mit Avatar-Cache und Kontakt-Discovery.
Crazy-to-Bike
•Ja, das habe ich inzwischen dank eines anderen Hinweises schon entdeckt.
Ich habe das Speicherbackend mal auf einen Ordner umgestellt. Damit ist die Datenbank nur noch knapp 40 MB als gepackte sql.gz
Die Frage ist, ob es mit Datenbank Backend performanter wäre 🤔
Hängt natürlich auch vom Serversetting ab, wie performant eine große Datenbank ist.
Der Worstcase, dass man ein Backup zurückspielen muss, ist imho mit kleiner Datenbank weniger problematisch.
Dateien muss man nur wieder hinkopieren. Da kann wenig schief gehen.
Wenn es keine wirklich triftigen Gründe gibt, die Datenbank als Speichetbackend zu nutzen, lasse ich es glaube ich erst mal mit Ordner.
Als Fragezeichen dargestellte Emoticons hatte ich auch davor schon. (Siehe anderen Post dazu im @helpers@forum.friendi.ca)
Warum das teilweise bei Emoticons im Anzeigenamen oder Beitrag so ist, wüsste ich ja schon gern.
Bei Leuten, denen ich folge, konnte ich das im Anzeigenamen und Profil mit "Kontaktdaten neu laden" beheben.
An anderer Stelle geht das natürlich nicht. Würde ich aber trotzdem gerne beheben.
Raroun
•Meiner Meinung nach ist es in erster Linie eine "Religionsfrage".
Es gibt die eine Ecke, die sagt, dass Dateien ins Dateisystem gehören und es gibt die andere Ecke, die gerne "alles an einen Platz" haben.
Ich gehöre zur Datenbankfraktion, weil ich mir im Desasterfall nicht (für mich) unnötige Arbeitsschritte einhandeln möchte wie Dateiberechtigungen etc.
Aber auch dazwischen gibt es viele Grauzonen.
Wenn ich einen Server mit super schnellen NVMe-Storage habe, aber kaum RAM, würde ich wohl auch eher zum File-Storage greifen.
Wenn ich einen Server mit etlichen GB RAM habe, sehe ich dazu keine Notwendigkeit, weil sich die Datenbank im RAM austoben darf.
Den File-Storage kann man auch in die Cloud auslagern beispielsweise mit einem S3-Storage. Aber so groß ist wohl derzeit keine Friendica-Instanz, als das es für mich persönlich in Frage kommen würde - vom Datenschutz mal abgesehen.
Bezüglich der Emoticons - keine Ahnung. Wenn Du es über "Kontaktdaten neu laden" beheben kannst, stehen die Chancen gut, das beim nächsten Kontakt-Abgleich sich das Problem vielleicht von alleine löst
Administration - Seite Automatisch ein Kontaktverzeichnis erstellen - Intervall zwischen den Tagen
.Crazy-to-Bike
•Ja, vermutlich ist es auch eine Glaubensfrage 🤣
In dem Fall bin ich Team Dateisystem. Da sehe ich genau, was passiert und kann extrem niederschwellig Probleme analysieren und beheben als auch Daten transferieren.
Eine Datenbank muss man zurückspielen und dabei kann es schon mal zu Problemen kommen, insbesondere wenn die riesig ist.
Danke für den Hinweis zum Intervall für das Erstellen des Kontaktverzeichnis. Das habe ich jetzt mal von Standard 7 auf 1 Tag gestellt.
Mal sehen, ob es hilft.
@Friendica Support
Crazy-to-Bike
•Also seit ich von Datenbank auf Dateisystem umgestellt habe, werden deutlich häufiger Profilbilder beim Seitenaufbau nicht geladen. Beim Reload mit F5 zerhagelt es manchmal die gesamte Darstellung.
Ich vermute, dass ich, wenn ich tatsächlich eine eigene Instanz betreiben und bei Friendica bleiben will, möglichst bald vom #Webspace, auf dem das gerade läuft, auf einen #vServer mit mehr Leistung umziehen sollte.
Die Daten werden offensichtlich nicht schnell genug ausgeiefert und wahrscheinlich kommt es auch beim Erstellen des Kontaktverzeichnisses zu fehlern, wenn die Perfomance zu gering ist 🤔
Vielleicht löst das auch das Problem mit den teilweise nicht dargestellten Emoticons 🤔
Raroun
•Möglich 🤔
alfredb
•Ich habe scheinbar eine ähnliche Situation wie du, kann aber die von dir beschriebenen Probleme nicht feststellen.
Crazy-to-Bike
•Ich bin aktuell der einzige aktive Benutzer.
Aber mein Webspace ist nicht sonderlich leistungstark, dafür dass da schon 2x Joomla und 1x Nextcloud (umfangreiche Nutzung) drauf laufen.
Vielleicht habe ich auch in der Friendica Administration zu viel aktiviert 🤔
z.B. hatte ich unter Seite --> automatisch ein Kontaktverzeichnis erstellen --> Endecke folgende und gefolgte Kontakte von Kontakten auf "Interaktionen".
Nachdem ich das mal auf "Keine" gestellt habe, ist das Laden der Darstellung im Browser deutlich flüssiger und ohne die ständigen Designaussetzer.
Woran das mit den teilweise nicht korrekt dargestellten Emoticons in Benutzernamen und Inhalten liegt, keine Ahnung. Da es bei den Benutzernamen und Profilen von Leuten, denen ich folge aber durch Neuladen der Profile behoben wurde, vermute ich, dass mein Webspace einfach immer wieder zu wenig Performance hat und dadurch Fehler beim Laden entstehen. 🤷♂️
Wie viel CPU & RAM hast du denn auf deinem Webspace und was läuft da sonst noch drauf?
Hast du die Daten in der Datenbank oder im Dateisystem?
Was für HDs / SSDs, NVMEs sind da bei dir drunter?
Bei mir ist das halt nur 1024 MB RAM garantiert und 16 Kunden / CPU Kern.
Das hat bisher gereicht, aber bei einer Friendica-Instanz ist halt schon Rechenleistung / Performance für die ganzen Interaktionen und Dinge wie Kontaktverzeichnis erstellen nötig.
Crazy-to-Bike
•ich habe jetzt mal versucht, Performance-Optimierung zu betreiben, wie hier https://wiki.friendi.ca/docs/improve-performance beschrieben, so weit das auf einem Shared Webspace überhaupt möglicht ist.
Was ich allerdings nicht in der Friendica Administration finden kann, ist
"OStatus conversation completion interval" und "Use MySQL full text engine"
Das reduzieren der Bildqualität von default 100 auf 50 war daher so ziemlich das Einzige, was ich bislang ändern konnte. Gefühlt hat da aber die Ladezeiten und die fehlerhafte Darstellung massiv verbessert.
Crazy-to-Bike
•Könnte sein, dass das Reduzieren der Bildqualität von 100 auf 50 auch das Emoticon-Problem beseitigt hat, auch wenn ich diesen Zustammenhang dann nicht ganz kapiere. Seit dieser Änderung sind jedenfalls keine ominösen Fragezeichen mehr in den Profilen und Beiträgen neu aufgetaucht, wo keine hin gehören.
Bei Beiträgen, die älter sind, ist es allerdings noch immer so. Aber das kann ja auch am Caching liegen 🤔🤷♂️
Heiko
•Hatte dann einfach mal kurz mein Storage-Verzeichnis (das, was man beim Speichern via Filesystem und nicht Datenbank einträgt) und Smarty auf -R 777 gesetzt - Ei, guck... plötzlich alles nach und nach wieder normal.
Bilder zu komprimieren lohnt sich wohl eher, wenn man wirklich nur in die Datenbank speichert... bei Mangel an Gesamtspeicherplatz bringts natürlich schon was.
Ich verfahre übrigens so: "Erlaubte" Uploads derzeit zum einen bis max. 6MB, bei maximaler Kantenlänge Höhe od. Breite bis 1200px. JPG-/Bildkompression dabei so zwischen 86% und 89% - alles andere lässt mir die Artefakte doch zu offensichtlich werden.
Lass Dich vom bei mir eingestellten Arbeitsspeicher nicht abschrecken. Damals, bevor ich mir wegen NextCloud und meinem DICOM-Viewer-Gedöns usw. nen Server nahm, da hatte ich Friendica bei meinem Webhoster in nem Shared-Web mit damals 384MB RAM laufen. Ging einwandfrei!
Allerdings hatte ich auch nur 3 oder 5 Worker eingestellt, aber das reicht ja für ne 1-2-3-Personeninstanz ohne Schickimicki aus, meine ich.
@Raroun @alfredb
Crazy-to-Bike
•Der Ordner hat 755 wie es sein soll.
Ich wüsste nicht, wie ein 777 etwas helfen soll, da ja eh nur der Besitzer schreiben und lesen muss/will.
@Raroun @alfredb
Heiko
•Auch, wenn ich das Warum schon gern geklärt wüßte.
@Raroun @alfredb
alfredb
•Heiko
•